Coding Style

I feel like I've got a clean, easy to read, style of programming. Maybe I'm wrong, I'm sure everyone feels that way.

Here's a list of practices I adhere to (in no particular order):
  • Entire methods should fit on a screen
  • Microsoft's Naming/Capitalization Conventions
  • I favor long descriptive names over brevity.
  • I always use "var" unless there's a good reason not to.
  • In many cases properties and local variable names are nothing more than the type name.
  • Properties are public and protected, fields are private.
  • I favor convention over configuration.
  • I always try and name methods or variables in way that makes comments unneeded.
  • I hate nesting if statements
  • Repositories usually contain some or all of the following methods GetAll, GetById, Save, Remove
  • I strongly promote the use of dependency injection
  • I promote the use of unit and integration tests
  • I promote the use of interfaces
  • I attempt to follow the SOLID principals as best I can.

Pet Peeves (the following is nothing but a big rant):

I'm a big stickler for Casing Conventions. To me there's not a worst first impression, then to open a project and see inconsistent or a lack of naming conventions. I don't want to see "local_variable" or "localvariable". I don't want to see lower case class and method names. I want to "_privateMember" and know for sure it's a private field in that class.

I also can't stand initialized variable names.
SomeClass sc = new SomeClass();
I much prefer:
var someClass = new SomeClass();

It drives me nuts when I find code method calls or logic on the return line.
Example: return DoSomething(myVar);
When this kind of code is chained 2 or levels deep it's very difficult to breakpoint.
I much prefer placing those in a variable:
var doSomethingResult = DoSomething(myVar);
return doSomethingResult;
Now anyone is able to breakpoint on the return line and see the result of the method call or logic.

I do like extremely long parameter lists in constructors, I'd rather pass an object with set properties.

I do not care for the singleton pattern where they use a .Instance() static method. In most cases I've see there's either no reason for the class to be static or it's just a collection of stateless methods and they should really all just be static methods. I would gladly argue that a dependency injection framework would allow you better control of the scope of objects rendering the singleton pattern fairly useless.

I HATE extremely large web.config or any any really long files. At my current company, we have numerous files over 2000 lines long. Our web.config is close to 3000. Someone decided to put everything under the sun in the web.config. I would rather see some other type of config file. Changes to the web.config cause IIS to reset. Create a settings class and serialize it to a file.

I also can't stand pointless abstraction. In this one project I worked on, they constants mapped to app.config properties (over 200). Then they created get properties for each one of those constants, which pulled the properties from the app.config. Then they actually had methods... that did some checking on the properties and set a default value.

{/*** I need to move this to a different section ***/}
I'm also not a fan of ORMs. I think they look great on the surface, especially when you look at the examples. No SQL... just code! It's so easy! I think these work for very small projects, however, to me they quickly lose their appeal with big projects. It's a huge pain coming into a project you didn't code and having trying to figure out what data is coming from where. Usually you run into a situation where you need to do some crazy join the orm doesn't support. That when I "clever" solution is devised that wouldn't be easily understood to someone else. They also take the developer away from SQL and writing good queries. The biggest issue I have with the ORMs I've used, is that they don't support clustered keys. Many of the ORMs end up reaching a similar level of complexity as just doing straight SQL. That's why I love LINQ2SQL, I only use stored procedure feature.

Last edited Sep 14, 2013 at 8:18 AM by amsprich, version 3