Coding Style matters. A lot.

Well, it’s been long since I don’t write! Wind is blowing and I have to adjust the sails🙂 A new adventure is coming!

But let’s get into the topic. I’m always looking for the best way to make my code shine and I usually ask questions that a lot of people consider silly. Coding style is something I’m very sensitive to. I have my own preferences, of course, and I’ve adopted most of them reading and listening to a lot of experts, reading code from them and following their guidelines. But there are other preferences that grew on me just as I wrote code. Since I met Robert Martin’s books and read as much as I could about Clean Code and the best coding practices, I evolved towards a very personal style, but I still have some doubts about it. I will try to describe it for you to criticize it if you wish :)  The coding style I will describe corresponds to C#, of course.

  1. Mostly, I adhere to coding standards and conventions. I have already mentioned ReSharper from JetBrains as a source to make my code “compliant”. 95% of the naming conventions coincide with the defaults that ReSharper uses.
  2. Something that annoys a lot to some developers: I use “var” instead of explicit types in declarations. ALWAYS. I have never had any problem with this and I consider that my code is legible enough to know at the very first glance which type a method returns. I prefer the compiler to infer the type than writing it twice. My methods are short, names are meaningful. Why should I write a line like “IEnumerable<clients> clients = host.Clients” instead of “var clients = host.Clients”?
  3. I have not seen any reason to seal a class. So I DO NOT seal my classes. Why? I don’t want to force a limitation. Inheritance is a basic OOP feature. Sealing classes by default is like assuming that implementers are going to fail miserably! Trust them: if they want to derive from your class, think that they’re going to do it well. If you allege that your base class deals with security, then it’s OK. Seal it! I cannot think of another reason.
  4. Private fields: NO UNDERSCORES, AT ALL! It’s ugly and remembers me of the 90s when we IntelliSense wasn’t there. Clean names, no prefixes, just good names.
  5. No orphaned lines.
    This is GOOD.
    Imagen
    This is BAD.
    Imagen
  6. And one last and strange characteristic that my code has: I don’t usually use private fields!!  How is that? Well… I consider properties are far more useful than fields: You can have an automatic property and use it as a field in a class without any problem. The good thing about it is that in a getter or (mostly) in a setter, you can perform additional operations like calculating derived properties, raising an event or anything that is needed whenever a field is going to be set, like attaching to events. So, most of my classes have a lot of private properties and the instance itself uses properties, not fields. This makes the usage of the “this” keyword almost unnecessary because you can assume that assignments like Clients = new List() are referring the instance. If you had “clients = …” you don’t know whether it’s a local variable or a field, so you should specify “this.clients”. It’s OK for me and the resulting code is pretty clear.

And that’s all for now🙂

What do you think?

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s