On Tue, 14 Dec 2004 16:14:32 +0100, H.Merijn Brand <[EMAIL PROTECTED]> wrote: > On Tue 14 Dec 2004 16:04, "Clayton, Nik" <[EMAIL PROTECTED]> > wrote: > > I've normally got enough going on in my head when writing code, > > worrying about the house style should not be one of them. > > Wrong. It should be. You write, and someone else - or yourself - has > to maintain the code later. This means that you have to write with > style and maintainability in focus. All the time.
Part of the problem is that "coding style" mixes a bunch of unrelated issues of varying importance. I'm with Nik that I don't care overmuch about how many spaces go around parens, whether curlys are cuddled or uncuddled, or tab expansion idiosyncracies. But there *are* issues of coding style that are of tremendous import, and can add or reduce friction on a project, especially as it grows. Things like line length, method length, naming conventions, file layout, idiomatic usage[*], etc. One example I've used in the past is from a project I worked on (in C) where we were dealing with "real estate data numbers", commonly abbreviated 'rednum'. Except that they were also named, 'red', 'redno', 'rnum', 'red_num', 'red_no', 'r_num', and so on. In both variables and functions. This was one of many sources of dissonance (and compiler errors) on the project, and was a continual drag on team productivity. Instead of just *knowing* what you needed, you often needed to grovel through half a dozen source files to figure out what you *should* have typed. But we all used the same brace placement and indenting styles. ;-) > FWIW the style I use was decided upon back in the 80's when we (me and > 6 others) had to do a huge software project at school and we did > discuss style before we started. The biggest argue was about the > length of the variable names to use. This is where I think Uncle Bob is right -- the standards need to evolve. On this same project, there was a coding standard in place at the onset, but it standardized trivialities. Because we had a coding standard, we never saw the bigger issues of naming conventions as problems a coding standard could/should fix, so everyone improvised in their own special way with the stuff that wasn't standardized. At the onset, though, a lot of issues we had to deal with were completely unknown, since the project took three or four major course changes over the years. Z. *: For example: design with closures and coderefs in mind, or with big modules with 17 optional features or 15 variations on the same method; are you intetionally using or avoiding map and grep?; what are the standard modules your project uses to write new classes?
