Narciso, on Software


Back on the road

Hello, it's been nearly a year since I last posted on this blog. It's really been a hard year, with no spare time. If you think you work a lot, try starting your own business.
My great project, Elondra, has taken almost all of my time, leaving a few for my familly and the university.
But I'm back now, I don't have free time, but I've decided to continue with this blog. I will probably post just once a month, but I will.
I'm working on a paper about J2ME, I hope you'll find it interesting.
Some time ago I started a corporate blog that you might find interesting.


Lightweight Containers and Plugin Architectures: Dependency Injection and Dynamic Service Locators in .NET

For many years I went from a project with MS technologies to another one with Java/Unix technologies, playing at both fields all the time. In fact, my main employer during that time (Digital / Compaq) made me go through the full MCSE + Internet certification path, so I was a bit more attracted by the MS easiness and productivity tools.
But I must admit that Java and J2EE presented a much more attractive approach for object oriented solutions, both from the developing perspective and even more from the architecting one. For the last three years I've been playing almost only with Java and J2EE, achieving a good proficiency level in that field, but leaving behind the .NET solutions that rivaled with them.
Now I've been playing with MS .NET for a while, learning basically C# which I think is the best language at .NET for real oo developers, and has all the easiness that only vb previously had (visual form development, asp coding, etc).
I think that C# is "stealing" a good deal of Java developers, and many of them try to bring solutions that have been developed for Java to the .NET architecture. This is happening with Open Source solutions, such as Ant (NAnt) or JUnit (NUnit) to name a few.
I think this phenomena is giving a lot of many good things and practices to the .NET community, and that is great.
But we must not forget that MS designed .NET with the knowledge of what's wrong at Java and J2EE, and also with a huge deal of great innovative minds, and there're many things already resolved at .NET that have been done by independent parties in the Java field.
Just to show a good example: now there's been a lot of effort and discussion about Dependency Injection or Inversion Of Control pattern and lightweight containers. We know about frameworks for Java like Spring, and many people is already doing ports of this kind of solutions to the .NET platform, when that is already addressed at the core of MS.NET.
The best thing about this issue being implemented at the core of .NET is that is something you can rely on, something you absolutely know people will be able to use without downloading and installing third party solutions like Spring.

Please, read Daniel Cazzulino's blog entry on the subject. He explains how this is addressed at .NET with clarity, making reference to the good article by Fowler on DI/IoC:

Lightweight Containers and Plugin Architectures: Dependency Injection and Dynamic Service Locators in .NET


Technical Careers @ Microsoft

I was tired of looking for information about how to build a good resume, what to do or not to do at an interview, and that kind of things. Often you find very general information, almost the same from one place to the other, nothing that adds value.
But I've found a wonderful site about this, it's a blog from Microsoft HR (nothing to do with catbert :-) ). The informal style, the diary approach, and the contents are simply great.
And the best part, it's devoted to Technical Careers (this post wouldn't be here otherwise).

Technical Careers @ Microsoft


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.


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


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.

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


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).