Monday, August 28, 2006

X-Period

This has been a long time since I have added a post here. Well, I will explain shortly the reason and let you know of my future plans.
Work - as lots of us know - took most of my time, but then a long summer vacation followed. I think I can consider this the next series of my posts (the new series), as soon enough there will be a year since I started blogging.
I plan to share my experiences frequently than so far I used to and of course, hoping this makes it easier for you.

Tuesday, May 09, 2006

Code, in general

Matthew Heusser wrote an article some time ago and he had a really good remark, pointing out that code which is produced is .. well, only produced and not exactly written to be of good quality. I read somewhere posted these days: "Quality pays itself." You probably have experienced this. But with Matthew's words, we don't get to say it too often: "Now that is some fine looking code".
He has some good points when defining beautiful code: code should be readable, focused, testable and elegant.

However I like to take his ideas a little bit further and add that code should be:
  • readable: good comments, coding styles should be respected, some common formatting styles should be followed
  • maintanable: variables, methods, classes should have talkative names, so when it comes to feature enhancing and/or refactoring software-parts shouldn't be just a collection of hard to understand, unreadable code
  • reusable: when it comes to adding new functionalities, especially methods should be organized that they don't contain duplicated code/duplicated logic and already existing feature should be taken advantage of
  • extendable: functionality should be organized so it is clear where new features fit best, and make use of object-oriented techniques
And code that was written with some consideration is easier to re-use, and to refactor. Code is usually refactored to make it more compact, more readable, as when refactoring code to introduce patterns, it is for later simpler reusablity and extendability.

Adrian Sutton also has put the point on the importance of producing quality code: "The other big advantage of writing beautiful code is that it demonstrates good coding practices to anyone who reads that code and anyone who reads beautiful code immediately has a high level of respect for the programmer and for the codebase. They're more likely to take time to understand problems and contribute fixes if they respect the codebase rather than seeing a mass of uncommented code, swearing at the programmers and going off to find a better written tool."

I don't agree with those people who say that generated software is of high quality when code from one programming language has been ported to a second language. Imagine a software written in Visual Basic and ported to C or Java. Imagine yourself now having to add new functionality to that software - it wouldn't be a dream job.

Finally, I think I have to add here that I am devoted to writing quality code: I am using, among other practices, the refactoring. Here you may find the catalog of refactoring to patterns, and you should also take into consideration the recently published Refactoring Databases.Of course, you can have the catalog of refactorings from here.

Technorati tags: software, code, programming, refactoring, practices.

Tuesday, April 04, 2006

Checkstyle - Coding standards

Quality code in my opinion is an important step towards quality software.

I believe having a well-defined set of coding conventions is necessary. To produce code that is readable, reusable and maintainable, it is needed (among other things like having good programming habits) to follow some code writing conventions. I use Eclipse for my IDE. And with it, Checkstyle - the tool that helps write Java code that adheres to a coding standard.

There exist many coding standars. For personal use, I recommend the easiest form: to follow the Sun coding conventions. Of course, you may personalize it. This will help you in coding and your code, to have a standard format. In case of companies, they tend to have different coding standards: you have probably experienced a few, if you have worked already for a couple of different companies. As companies usually develop their own coding standards, sometimes very different from the Sun coding conventions, other times with minor alterations. This is good in either ways: code within a company needs to be maintained, reused, and improved. So this is a small assurance of better code. When a programmer or programmers have a well defined set of coding standards, they will think less about details such as code layout and variable naming conventions, spending more time on the real coding.

Some coding conventions that I find important:

  • Comments: all classes, methods, and variables should have
  • Naming conventions: constants should be in uppercase; variables, methods should have talkative names and should not be abbreviated
    (e.g.: private Map myHashMap;);
  • Declaration: all variables should be declared with visibility modifiers; each declaration should be on separate line

Checkstyle can check many aspects of your source code. You may want to give it try, as it now supports features like: checks for class design problems, duplicate code, and standards related to: Javadoc comments, naming conventions, import statements, white space, modifiers, blocks, etc.

If you already want to add it to your Eclipse IDE, you may find here some hints. As well, you are able to set various highlighting modes.


Technorati tags: Checkstyle, Eclipse, Java, tool, tutorial.