3 ms·
Some good points there. When it comes to source code, I believe that it all boils down to how detail-oriented the programmer is, and the source code will be a r
by raju 19y ago
Some good points there. When it comes to source code, I believe that it all boils down to how detail-oriented the programmer is, and the source code will be a reflection of that. Everything from formatting, white-spacing to method/variable names counts
I have come across places where a programmer chooses to name a variable "temp" rather than giving it a descriptive name, and that annoys the snot out of me. Even if it a temp (and which local variable isn't, in a language like Java) take the time to think about it and name it appropriately!
Some pointers that I use for maintaining source code readability -
1. Impose a formatting standard on the team (tools like Eclipse have built in formatters, and if that does not work, use a third party tool like Jalopy)
2. Code reviews should include code presentation style. This involves method/variable naming, ordering of arguments in methods [I swear, I have come across overloaded methods that have different ordering of arguments]. One trick I use a lot came out of Martin Fowler's Refactoring books, and its "Do not be afraid of one-line methods".
Going back to the example the article shows,
if (some_really_longgggggggggggggggggggggggggggggggggg_condition &&
another_really_longggggggggggggggggggggggggggggggggggg_condition) {
handleIt();
}
I would rather do
if(isAppropriateInThisSituation()){
handleIt();
}
and encapsulate the long if inside isAppropriateInThisSituation. Self documenting, yes?
3. Small methods, please! Another rule of mine, try and keep the method short. I agree sometimes this is possible, but a lot of people write code as they think it out, and never go back to leverage reuse and improve readability. 9 of 10 times, you can and should.
4. Finally, use the tools that are provided. Eclipse has an optimize imports, format and cleanup source code functionality. Train yourself to run these before checking in files. You can even set up triggers within CI (like CruiceControl) to automatically format the code base on every delivery.
Again, a lot of this rant comes from the Java world. YMMV