Prev: Attribute denoting a subprogram : no named parameter associations allowed
Next: Question on array of strings
From: Stephen Leake on 1 Nov 2009 03:24
Jacob Sparre Andersen <sparre(a)nbi.dk> writes:

> tmoran(a)acm.org wrote:
>
>> Since you probably write variable names much more often in the code
>> than the type name, it makes sense to try to shorten them, at the
>> expense of slightly longer type names.
>
> Now I simply have to quote Preben Randhol:
>
> "Saving keystrokes is the job of the text editor, not the
> programming language."

Yes, but reading is also important. The _Type suffix is essentially
noise when reading; it's only there for the compiler, not the human.
So you want to read it as few times as possible, as well as write it
as few times as possible.

--
-- Stephe
From: Peter C. Chapin on 1 Nov 2009 05:18
Stephen Leake <stephen_leake(a)stephe-leake.org> wrote in
news:u4ope4pqa.fsf(a)stephe-leake.org:

> Yes, but reading is also important. The _Type suffix is essentially
> noise when reading; it's only there for the compiler, not the human.
> So you want to read it as few times as possible, as well as write it
> as few times as possible.

This seems backwards to me. I could use a type name such as X72efY9 for all
the compiler cares. The _Type suffix is most definitely for the human. It
says, "Hey! This is the name of a type so keep that in mind when looking at
this code."

In the past I used _Type as a suffix for all of my types. However, there
are times when that doesn't seem to fit. After all the standard types don't
(usually) use a _Type suffix (Character, Integer, Positive, Vector, etc).
Lately I've become a lot less strict about using _Type suffixes in my code.

Peter
From: Hibou57 (Yannick Duchêne) on 1 Nov 2009 08:01
Suggested reading : http://p.einarsen.no/programmer-personality-types-and-why-it-matters-at-all/

This may not be obviously related to naming convention, but please,
read, this is related to “ understanding each others ”

This may throw light on two points :
1) why it appears we encounter difficulties in agreeing about a common
convention
2) why we should agree on a common convention

(both)

A quote from this article :
> That is also a good thing to keep in mind when formatting code for
> readability: if your coding style differs from standard Perl Tidy or
> your company’s coding standard, keep in mind that you are not
> formatting for yourself, but a colleague, maintainer or anonymous
> CPAN downloader. They are more likely to understand a common
> standard than your standard. It sounds obvious, don’t it? I don’t
> think many (any) programmers think like this even so.

Thus the need to agree, which in turn make it less difficult a
situation where yours and others may match

( we may suppose formalization and explicit rationals may help to
agree )

Note : when I've though about posting this quote, I've made the
assumption this is also applicable when peoples are not working for a
common company and even when they are working alone but not in their
strict own purpose
From: Hibou57 (Yannick Duchêne) on 1 Nov 2009 08:40
This one does not give a lot of reasons to rejoice :
http://p.einarsen.no/category/understanding-code/

It simply ends with a “ But do keep in mind that the research is still
a bit patchy, and this is mostly an argument without empirical data. ”
From: tmoran on 1 Nov 2009 19:30
Regarding _Type as lengthing names, Pascal's comment seems appropriate:
"I apologize that this letter is so long, I lacked the time to make it short."
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11
Prev: Attribute denoting a subprogram : no named parameter associations allowed
Next: Question on array of strings