Showing posts with label clean code. Show all posts
Showing posts with label clean code. Show all posts

Wednesday, February 1, 2017

Fix Your Coding Style Cause it Causes Errors!


This enthralling academic paper http://web.stanford.edu/~engler/p401-xie.pdf titled "Using Redundancies to Find Errors", came out of Stanford in 2002. It shows that analysis of redundancies in code "seemed to flag confused or poor programmers who were prone to other error types."


Some examples of the kinds of redundancies mentioned in the paper include: unused variables, reassignment of variables for no purpose, mathematical redundancies such as x/x, x|x, etc., logical branch and case statements which either always eval to true or false or are never reached, dead code - statements that are never reached due to an early break or continue in a loop.


Most of the examples given in the paper are the result just plain sloppy and/or lazy programming style. You see it too many times - copy-paste code, terse conditionals, disconnected variable names, poor structure and flow. My advice to anyone seeking to get better at programming is to reread your code before you commit. Write it three times - once to make it work, a second time so you can read it and a third time so everyone else can read it. When your done with it, you should be able to show one of your QA engineers the code and they'll know what it does! Then you know what you should do? Rewrite it again - this time to make it more concise, you could be missing out on something important like an opportunity to reduce the size of the code base, crate some reusability, or remove some diabolical nested if statements (one of the worst sins of programmerkind).


Look, if you were writing a book, would you be allowed to write the first draft and sell it as soon as you've written the last word? Hell NO! No one would want to read it anyways. It would contain several grammatical errors as well as redundancies, illogic, contradictions, and shit that just plain don't make any sense! Why would you abuse any language in such a manner? Languages are made to communicate. Programming languages are no different.

Sunday, April 3, 2016

Contain Dependencies

This has come up several times in various applications I've worked with. You have some dependency - lets say the MVC framework for example. That dependency is a certain version, lets say 4 for sake of discussion. You have multiple csproj files in your Visual Studio solution. One of those projects is the ASP.NET MVC 4 web project, another is a bunch of models, maybe another contains a collection of helpers. One of those projects which the web proj depends on also depends on MVC, but also has some other dependencies like StructureMap or NHibernate or Automapper.


Now imagine one or more of those projects is shared amongst multiple solutions since it contains re-usable code. If any of those projects have a 3rd party dependency updated to the latest (and greatest?), what happens to the shared project? It too must be updated. Once that happens, all other solutions which use it are impacted. But what if the consuming code doesn't even use the feature that depends on the 3rd party lib? Now you're stuck holding the bag anyways...


So here's the lesson - if you're writing a lib that is intended for re-use, separate any pieces of code that have external dependencies onto their own assemblies. For example, of you have a library of helpers, have a library of core helpers then a library of helpers for each other external dependency.


Helpers.
Helpers.MVC.
Helpers.EntityFramework.
Helpers.Automapper.


Maybe even version them if you see fit.


Helpers.MVC4.
Helpers.MVC5.


By separating those dependencies this way, you can avoid potentially crippling issues down the road where suddenly your applications won't compile and you don't know why. When you finally find out, you have to wade though oodles of muck to sort it all out. Plus its just good SoC :)


Happy Coding!