4 ms·

Applying User Interface Design to Source Code

1 points by luccastera 19y ago

brentr 19y ago
This is a great article. The section concerning self-describing code really hit home. Comments can, at times, be more distracting than helpful. If one chooses to appropriately name code items, it is my belief that comments become unnecessary clutter. One of the methods I use for clarity when writing object-oriented code is as follows: only getters and setters touch the private data members. The only problem with this approach is if performance (i.e. speed) in your system is an issue; there is a lot of overhead in calling the getters and setters. What methods do other people use for maintaining source code readability and separation of concerns? EDIT: For clarification, when I state that one should use only setters and getters to access private data, I mean that other public methods in the same class should be calling the setters and getters instead of accessing the private data directly.
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

1 points by luccastera 19y ago

This is a great article. The section concerning self-describing code really hit home. Comments can, at times, be more distracting than helpful. If one chooses to appropriately name code items, it is my belief that comments become unnecessary clutter. One of the methods I use for clarity when writing object-oriented code is as follows: only getters and setters touch the private data members. The only problem with this approach is if performance (i.e. speed) in your system is an issue; there is a lot of overhead in calling the getters and setters. What methods do other people use for maintaining source code readability and separation of concerns? EDIT: For clarification, when I state that one should use only setters and getters to access private data, I mean that other public methods in the same class should be calling the setters and getters instead of accessing the private data directly.

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