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.