2 ms·

We are far too willing to dismiss things as mere "personal preference" in this industry. There may be competing theories all supported by some empirical evidenc

We are far too willing to dismiss things as mere "personal preference" in this industry. There may be competing theories all supported by some empirical evidence and sound logic, but some claims are directly contradicted by hard data. Those claims are not just a personal preference for the best way to do things. They are measurably, objectively wrong, and failing to say so is just being nice because we don't want to criticise someone. On the evidence I have found to date, I am coming around to the view that the style of writing many very short functions (say up to 5-6 lines) with little complexity in the logic (say just a single level of nesting) is one approach whose claimed superiority is directly contradicted by empirical data. For example, McConnell discussed the number-of-lines issue in Code Complete years ago, citing multiple studies. Anyone can find still more by investing a few minutes in Google Scholar searches. Alas, that does not stop bloggers, consultants, trainers and book authors from advocating this programming style, even though it invariably results in the kind of incohesive "spread" that the article mentioned.

dkarl 17y ago
Code that falls in line with your expectations and caters to your mental toolkit is easy to understand. It also helps when code works well with your existing programming environment. I work with Java programmers and C++ programmers, and they both have ways of jumping quickly to class and method definitions, but the C++ programmers' way -- incremental search -- only works within a single file. The Java programmers barely notice that they're hopping around in the filesystem like Q-bert. The C++ programmers, working in emacs and vi, come to a grinding halt when they need to hop around to many different files in different directories, probably because they almost never need to do that. (It may seem like the Java programmers simply use more capable tools, but most of them don't use incremental search at all, so they're much slower at finding something that they don't have a hop-to-X button for. Why? Because they get by fine without it, just like the C++ programmers get by without learning whatever emacs or vi extension would help them navigate Java-style source directory hierarchies.) Obviously some kinds of tools and programmers will be more common than others, so one style can be empirically better than another yet be worse for a particular group of programmers. There won't be one better way of writing code until everybody has the same expectations and the same tools. I don't think we ever want to reach that kind of consensus.
- Chris_Newton 17y ago
  I'm certainly not advocating complete uniformity in how everyone does everything, but I think we have to be careful about judging programming style based on artificial limitations. Static code navigation, on the level of your examples, is essentially a solved problem. If the developers you work with are using tools that can't do it, or aren't using the tools they have to best effect, then they have a basic problem that has little to do with coding style.

dkarl 17y ago

Code that falls in line with your expectations and caters to your mental toolkit is easy to understand. It also helps when code works well with your existing programming environment. I work with Java programmers and C++ programmers, and they both have ways of jumping quickly to class and method definitions, but the C++ programmers' way -- incremental search -- only works within a single file. The Java programmers barely notice that they're hopping around in the filesystem like Q-bert. The C++ programmers, working in emacs and vi, come to a grinding halt when they need to hop around to many different files in different directories, probably because they almost never need to do that. (It may seem like the Java programmers simply use more capable tools, but most of them don't use incremental search at all, so they're much slower at finding something that they don't have a hop-to-X button for. Why? Because they get by fine without it, just like the C++ programmers get by without learning whatever emacs or vi extension would help them navigate Java-style source directory hierarchies.) Obviously some kinds of tools and programmers will be more common than others, so one style can be empirically better than another yet be worse for a particular group of programmers. There won't be one better way of writing code until everybody has the same expectations and the same tools. I don't think we ever want to reach that kind of consensus.

Chris_Newton 17y ago
I'm certainly not advocating complete uniformity in how everyone does everything, but I think we have to be careful about judging programming style based on artificial limitations. Static code navigation, on the level of your examples, is essentially a solved problem. If the developers you work with are using tools that can't do it, or aren't using the tools they have to best effect, then they have a basic problem that has little to do with coding style.