Narciso, on Software

5.29.2004

Modeling tools from Microsoft

I'm very happy that new modeling tools like these will arrive to the software community.
It's a very promising approach to design, to improve RAD and software quality, and aligned with agile methodologies.
Please, take a look at this post on TheServerSide.NET, and don't forget to follow the links that Dion points out, they're very worth reading.

5.27.2004

JetBrains ReSharper

There're many editors and IDEs. I've tested many of them during these years, but there's one that "made me fall in love for the first time". It's IntelliJ Idea, from JetBrains. You can download a trial version, or even better, register for their EAP and try their work in progress.
There're probably other IDEs with better GUI capabilities, but none with the advanced editing ones from Idea. Idea provides many time-saving features, going ahead with new trends in development, such as integration with ant, JUnit, aspects, generics, and it provides extensive refactoring capabilities.
Now, the guys at JetBrains want to surprise us again with another wonder: ReSharper. ReSharper is a plugin for Visual Studio .NET 2003 that brings capabilities from Idea to the Microsoft IDE, greatly improving the C# coding experience. You can try it joining their EAP (it's still beta software with limited features), which I recommend.

JetBrains ReSharper

5.26.2004

Naming and style (II)

Well, here we get to the fun.
First of all, I must say that you must have a style guide for your company or project, and that will be your guide. There are many things at guidelines that can be considered subjective, and such things will vary accordingly depending on the reader / user.

I've put a link to a very comprehensive guide for C# from Philips, it is pretty C# specific, but many things can be applied to any object oriented language. I have to say that I don't agree to every point at it, and that I miss some explanations, but this is logical since it's something imposed to a development group and not a discussion, like this.
I find that this document mixes concepts on naming, coding format and coding style, which are different for me. I've talked a little about naming, to which I'll come back later. Coding format talks about the appearance, and how to improve code readability, and it's less language specific. Code style is more about coding techniques, and how to write better code. Every one of them try to improve code quality, but from different point of views. All are essential, and in concrete cases like this it may make sense to mix them, but I prefer to keep them apart.

I will address Code Format first, starting with things I think are objective, explaining their rationale. Later I will come to the subjective things, mainly related to spacing and length.
Afterwards I will address Code Style, splitting it the same way.

Remember, this is my blog and, so, I write here my own thoughts, which can be different from yours. I am usually in charge of defining this kind of things at work, and enforce them. Yes, enforce; when you are working for a company, you must adhere to the company's guidelines, even if they differ from yours. When you are coding at home, or you leave that company, you can use your own rules.

Let's start.

Declaring variables
I fully agree with the given document that variables must be declared where they are used, instead of putting all of them at the method beginning. This is one of the improvements that came with C++ over C, and a good one. If you declare a variable next to the block where it's used you ease refactoring, as you can take the whole block at once at move it to another method, for example; and if you happen to remove the block you won't miss the variable. More over, placing the variable next to the block using it makes it easier to understand its purpose.

Control blocks
Again I agree, that every control primitive (if, while, etc.) must be followed by a control block, even if it's empty. Even though C++, C# and Java allow to use no braces for simple control blocks (one line) that it's very error prone: if you later add a line to the block is rather easy to forget about the braces, it will compile, but the new line will not be in the block and the program will not work as expected. These kinds of errors are usually very difficult to spot.

Use spaces, not tabs
Many will say this is subjective, I say it's not. The reason is simple: spaces are the only way to guarantee that indentation will keep consistent at different environments. Typically, different systems show tabs different, and that applies not only when going from Windows to Unix, for example, but even at the same operating system between different programs. The subjective thing here is how many spaces we should use to perform indentation. I use four spaces, but that is subjective.

Indentation
You must use a good and consistent indentation style. That's objective. The rest about it is subjective, and I feel I will make a single post on the subject with my own preferences. Indentation is much related to the maximum line length, which will be addressed at my next post.

And I think these are the few objective things about Code Format.

Philps' C# Coding Guidelines

5.25.2004

Naming and style (I)

Fortunately, there are many people using well defined naming and style conventions. But, through my professional life, I have got the doubtful privilege of bumping into many others that not.
I must say that this does not only happen at what we should call low tech profile environments, but also at top consulting firms. In my humble opinion, this is a result of the indiscriminate hiring during the .com fever (at least in Spain).
This is one of the essential factors to get quality code, and the first step of a chain where you can find Kent Beck's and Martin Fowler's refactoring, and the bigger the project or team, the higher importance it gets.
During the innumerable years that I have been coding, my style and naming conventions have been changing, adapting to the new environments and languages, and improving with the acquired knowledge. And I am sure they will keep changing like something alive.
Today I will speak just about naming. I will further speak about style, which is much more interesting. I will focus on the most extended environments nowadays: Java and .NET.

Class names
Both classes and interfaces fall into this category.
During many years I used prefixes to name classes and interfaces, putting a C or an I before, respectively. In fact, .NET still uses this convention for interfaces, while Java makes no distinction. I think that the I has no value, and thus I have stopped using it. I think that interfaces are our face to the world outside (good practice: coding to interfaces), and their potential users don't care about the fact that it's an interface or a class, so the I adds unnecessary data and thus it just makes the style worse. However, it can be advisable to use it with .NET to keep coherence with the environment.
As a rule, class or interface names must be composed by one or more representative words, fully written unless they are well known abbreviations, properly capitalized at their first letter, and without underscores or other artifacts between them. Sample: DataObject.
As an extension, I think that it's a good practice to add the pattern name at the end, if the class follows one. Example: DataObjectFactory.

Public method and property names
My advice is to use the rules that the style guides give for the different environments.
For example, with Java the name is built the same way as already explained for classes, but with the first word in lower case. Example: provideSomeInfo().
With .NET the name is built exactly as for a class. Example: ProvideSomeInfo().

Private or protected method and property names
My advice here is the same as before, and follows the same pattern as public methods and properties.
Along many years I have used my own variation of Charles Simonyi's Hungarian Notation, from my C/C++ heritage, but certainly, more pure object oriented languages like Java or C# make it almost useless. Anyway it can be a good issue to discuss.

Some basic rules
It is essential that names are always representative of the method or variable role. Please, don't be afraid to write more, it will pay you when you have to came back a couple of months later.
This can only be bypassed for counters, used in loops, but restricted to those traditionally used in mathematics: i, j, k, m, n. And with that precise order. This is very important to keep coherence and prevent errors at intricate inner loops (which should not happen, but that's a matter of style).

5.24.2004

Closing the Gap, Part 2

The second part of this interesting article by Eric Sink gives us a couple of very helpful insights about the small-ISV business.
Eric teaches us how to know if our product has a market, and how to reach customers using the resources that we have at hand, such us blogs, where we can communicate with our possible users and learn from their interests or restlessness. The strategy is based on letting the customer be in control of the sales process, deciding what to buy and when. Sincerely, I think that this is a must read.

Closing the Gap, Part 2

Openning

It doesn't matter your profession, life is a learning path. But perhaps there are two things that make us learn faster: failure and people.
Failure teaches hard lessons, that can undermine our willing, but they make us wiser and help us taking better decisions, and that's the goal.
People teach us new ways of looking at things, and bring us more knowledge, but that is not possible without interaction (failure is something very intimate and personal). This interaction has to be strengthened every day, at work, at home and thanks to blogs we can now extend that communication to the whole world.
So you just know what I am trying to do with this blog: be richer (intellectually and humanly ;-) ).