
Applying User Interface Design to Source Code - luccastera
http://www.bbsinc.biz/articles/applying-ui-principles-to-source-code.html
======
brentr
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
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

