Breaking backwards compatiblity

[H. S. Teoh]

On Sun, Mar 11, 2012 at 11:31:33PM +0100, deadalnix wrote:
> Le 11/03/2012 21:16, Walter Bright a écrit :
[...]
> >I'm not suggesting no naming convention. Naming conventions are good.
> >But they don't trump everything else in importance, not even close.
> >
> 
> I have to disagree. They are really important on a large codebase (let
> say > 100,000 lines of code). Otherwise people tend not to find
> modules they can reuse expect by nowing the whole codebase. This have
> indirect effect to cause needless duplication - with all known
> drawbacks - and make the project more dependent on documentation -
> more documentation have to be produced, which means an overhead in
> workload and more trouble when documentation lacks, is outdated, or is
> bugguy.

I used to be very much against verbose naming conventions. Almost all
naming conventions are verbose, and I hate verbosity with a passion (I
still do).

But after having been forced to use naming conventions in some code at
work, I'm starting to see some value to them, especially in very large
projects where there's so much code that without some sort of
convention, it quickly becomes impossible to find what you want. Due to
lack of convention, one team tries writing code with what they feel is a
consistent naming, then another team comes along and do the same, and
they run into naming conflicts, so they rename stuff haphazardly. Repeat
this over a few iterations of the product, and you end up with 50
modules all with inconsistent naming due to historical conflicts.

Code readability thus drops dramatically, and people coming on board
later on can't understand what the code was supposed to do because it's
all so obtuse (and they don't have the time/energy to wade through 5
million lines of code to understand every little nuance). This, plus the
time pressure of impending deadlines, cause them to resort to
copy-n-pasting, second-guessing what a piece of code does without
bothering to check their assumptions (since it's so obtuse that looking
up *one* thing would cost them hours just to even begin to understand
it), and all sorts of bad code enters the system.

Compare this with a project that has naming conventions from the get go.
Name clashes are essentially non-existent if the naming convention is
consistent, and if you're looking for a function in module X to do Y,
the naming convention almost already spells out the name for you. Makes
things very easy to find, and once you understand the convention, makes
code very easy to read (most guesses at what the code means are actually
correct -- in a large project, you *know* people are just going to write
what they think is right rather than spend time reading code to
understand what it actually does). So people are more likely to actually
write correct code, which means people who come on board after them are
more likely to understand the code and not do stupid things.


[...]
> IMO, the name in itself isn't that important. The important thing is
> that thing get named in a predictable and simple way.

+1.


T

-- 
First Rule of History: History doesn't repeat itself -- historians merely repeat each other.