It’s enounced by someone called “Suppa JMN” and states the following:
The code quality in a project is proportional to the number of total lines and inversely proportional to the product of the squared average of net lines of code by the number of classes named with the “Manager” suffix.
- N is the net lines of the project.
- M is the number of Managers.
- c is the net lines of code of a class (measured as average).
The following list illustrates the measurement:
- > 10. Code of extreme quality. Congratulations.
- 2 – 10. Code of good mother.
- 1 – 2. Average quality code.
- 0,5 – 1. Mediocre code
- 0,1 – 0,5. Turd.
- < 0,1. A shit the size of a piano. Burn the repository now.
You definitely have to take a look to these recipes! 🙂
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.
- 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.
- 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”?
- 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.
- 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.
- No orphaned lines.
This is GOOD.
This is BAD.
- 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?
Marc Andreessen provided some insights into the importance of software and the software profession’s ability to meet the need at “Why Software Is Eating The World” , http://goo.gl/ob2Cvx
Scrum facilitates control through frequent, regular inspection and adaptation of transparent software functionality. Transparency means the software is ready. It can either be immediately deployed or built upon without regression. It has no technical debt. Transparency mandates modern engineering practices and tools, and application of enlightened value-driven management.
I’ve found that most software developers do not have these skills. For example, the concept of building code from requirements and specifications that are then used as tests is incomprehensible to many.
Our shortcomings were surprising to me. When I rolled out Scrum, I thought that the excellent developers that had been stifled by waterfall processes would emerge, and we would again do great work and build great software. Much to my surprise…
Ver la entrada original 287 palabras más
Pure Candy for your styling glory!
This is a recommended read to solve a very common advanced topic: using selectors to retrieve a Getter and a Setter of a property 🙂