Chronological Thread 

< Chronological >      < Thread >

---

Hi all,

I feel that this is in essence similar to some of the problems in
writing user messages.

Against terseness, you do not generally want
"foo" or other metasyntactics as your message,
but sometimes a something like "NS_ERROR: 0x800F34" is both
metasyntactic, as it is a placeholder for something that is not
inherent within it, yet in that capacity is the most
descriptive and useful message for the intended audience.

On the other hand, there are situations where you need to find a
functional lie which is sufficiently terse, as the truth is too verbose,
in the sense that the user cannot extract useful meaning from the truth,
even though it is all explicitly there with no need for digestion.

An abbreviation is halfway between a metasyntactic varible and an
explicit name; one can still treat the name as a glyph, and
there is some equivocation over the expansion of the name.
In some cases I believe that the ability to treat the name like
a glyph leads to less equivocation over meaning than expanding
the name would remove. For example, expanding gcontext to
GraphicalContext removes any doubt over what the 'g' might
mean, but it does not tell you which particular thing which is
a graphical context like thing this variable refers to.
The variable 'ocanvas' could be thought of as a graphical context
like object, but it refers to a different thing.

That being said, I am more comfortable erring slightly on
the side of verbosity.

Regards,
Justin.

Randall Britten wrote:
> Hi all
>
> We're on the same page.
>
> I agree with not blindly following style guides, which is why they are
> called guides. I agree with using "i" for small loops. I agree with using
> standard acronyms (e.g. CVODE).
>
> However, our code has many more abbreviations than I think is good practice.
> I do not think we should try and fix these retrospectively. I think we
> should do this:
> 1) From now on, prefer avoiding abbreviations.
> 2) Expand existing abbreviations in code if you are working on that piece of
> code.
>
> Regards,
> Randall
>
>
> _______________________________________________
> cellml-tools-developers mailing list
> cellml-tools-developers at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-tools-developers

---

• [cellml-dev] Code style suggestion, Andrew Miller, 11/01/2007
  • [cellml-dev] Code style suggestion, Randall Britten, 11/01/2007
    • [cellml-dev] Code style suggestion, Andrew Miller, 11/01/2007
      • [cellml-dev] Code style suggestion, Randall Britten, 11/01/2007
        • [cellml-dev] Code style suggestion, Justin Marsh, 11/01/2007

---

Archive powered by MHonArc 2.6.18.