Re: Long names are doom ?

[Pete Thompson <blackpete@nowhere.somewhere.anywhere.com>]

On Sat, 2 Jun 2001 17:29:04 +1200, "AG" <ang@xtra.co.nz> wrote:

Youch.  I lost the thread a couple of days ago, and only managed to find it
just now.  I didn't realize that my post had sparked a bit of a sub-thread
there  :)  In any case, I'll try to address most responses in this single
post...

>> Methinks it would be far more productive to simply let the team members
>get
>> their job done rather than worrying about whether they're adhering to your
>> personal tastes instead of theirs...
>
>Well, they do need to talk to each other don't they? And how about the
>project
>manager just letting "the team members get their job done" ? I guess that
>*would*
>qualify as the perfect world:)

Yes, of course having a code convention is important in a team.  What I was
trying to get at was that if your standards are different from the
"conventional" standard for the language you're using, then perhaps it's your
own standards that needs to be looked at.  Of course, I'm no Ada programmer, so
I don't know what the standards are like in Ada.

But suffice to say that it would seem that the standards for Ada and C/C++ seem
to be different.  :/

>Like more erorrs? Do you really really claim that your productivity speed is
>only
>limited by your typing speed? You must be a very exceptional programmer if
>your
>productive speed is only limited by that ...

No, that's not what I was saying at all.  I'll try to explain better:

In most C/C++ code, I very rarely ever see anyone using an underscore in a
variable name.  When they do, they usually come from a Pascal background.

It's fairly standard for C/C++ (and Java it would seem) to simply capitalize
each word in a variable name (with the exception of the first word).  When
you're writing C/C++ code, your target audience is generally other C/C++
programmers who already follows the same (or similar) conventions.  Underscores
then become less needed. 

>Ummm, you are confusing things now - if you speak touch-typing, then
>underscores
>are no problem - any half-way competenet secretary can do that of course, no
>problem.
>However, that has nothing to do with the programming.

I'm a touch-typist.  I've been a touch-typist for longer than I'd care to think
about <G>, and therein lies the problem, actually.  My right hand's beginning
to feel the strain.  

You're right, medical issues have nothing to do with programming, but it *IS*
an issue, and it's growing bigger in the marketplace every day.  And it just so
happens that it's an issue that affects typing. 


>Besides, your example compares 3 characters to 5 characters (plus perhaps
>two spaces
>which shouldn't be needed as far as your theory is concerned) So, anyone
>really cares
>about the [fraction of a second] difference in typing speed as oposed to
>hours of design
>time?

re:  This_Is_A_Variable.

Those "3 characters" can quickly expand when you actually use that variable
name in a block of code (or more if it's a major variable name in an entire
program).  Plus you'd be using it in all the other variable names and function
names.  So we're not talking about only 3 characters.

>You must be a very bad typer then:) I note that the whole of your sentence
>above contains just 3 underscores but 7 blank spaces. So, how come the
>3 underscores took you longer then 7 spaces? Sure, technically speaking
>hitting the space bar IS faster then the underscore. *** But *** is it
>really
>your contention that this is what limits the speed of software development?

No, that is not my contention at all.  See above.

It's a bit unfair to compare the underscore to the spacebar.  The spacebar is
essential to separate keywords.  The underscore is not.  It's purely used for
readability issues.

>>  Reading
>> the code isn't much of an issue as long as you capitalize each word in the
>> variable name.  Yes, 'Thisisavariable' would be quite horrible.
>
>If only reading the code was as simple as that... You only need caps to read
>the code? Cool...

Yep.  Want a better example?  Try hungarian notation.

char* pszString;

It looks weird.  It looks clumsy.  And it stops typecasting errors cold once
you get the hang of it, and learn how to read it naturally.

The bottom line is that when you've been using a language for a long time, then
its conventions become second-nature to you.  It's a bit like a culture shock
when talking to programmers of other languages.

Just curious... but do you use perl?