This is a boring article about some of the basic best-practices and principals for writing software.  I have broken this down into concepts and the subsequent best practices and principals in software development.  This article is focusing on best practices for programming languages like Java, PHP, JavaScript and am using industry standard frameworks like Laravel (PHP), Spring MVC (Java), and Angular.js/jQuery (JavaScript).  This guide is not comprehensive, but hopefully over time it will be.

I know that there are a bunch of guides and practical programming guides on this, but since I am a programmer, everyone else’s isn’t as good as mine, so I decided I needed to write my own. Yup

Keeping Track of Stuff

History: Back in the day, we would copy files onto CDs or USB drives, or even email files, but the problem is that both Joe and Jeff have been editing these files, and then it’s a mess to track the difference between the two.  So software people came up with diff to deal with checking the difference between files.  Eventually, we came up with subversion, which manages the a bunch of these files in a central location.   That became a problem  because everything got bloated.  So here we are today.

Today, fancy people today call this “Version Control.”  Practical people call this GIT.  Git solves a lot of the basic problems with subversion and is the most widely used version control systems in the world.

Do you want a job in software? Do you want to not hate your life over, and over, and over, and over, and over… again (like I did)? Then learn GIT.  It’s free and super well documented.  Get a free account at GitHub.com.  For those of you that are “bash-fully” impaired, check out SourceTree.

Yes it’s annoying.  Yes it’s going to slow you down a little bit (a lot at first).  Yes, you will likely give up after the first try.  Yes, you will be back when you screw yourself over next time you do something stupid.

Commitments

Why are you so scared to commit? Make small changes at a time, one change, one thing at a time.  Focus on that, test it to make sure it works, and then commit it.  Is that so hard?

Oh, so you have this “big change” coming? Think you get out of it that easy? Ha! We already have an answer to that.  Check out Git Flow.  It is made just for that, plus, plus, plus.

What the Fork?

I don’t really feel like explaining this now, check out Git Flow. (It’s an eye catching title though, no?)

Where Code Goes

Second to where you put your code on your drive, where you put your code in your program is just as critical.

History: Back in the day, code was everywhere, like a water balloon full of red paint and diarrhea running through an industrial fan, code looked and smelled like crap.  It stunk writing it, working with it, was nearly impossible to change, and new developers had a 87.3% suicide rate.

Today, code is still pretty crappy, but the suicide rate is much lower anyways.  We solve this problem with code standards.

The big picture concept that has saved the lives of many developers: MVC, which stands for Model-View-Controller. This is a great theroretical appriach, but more likely today, we have the MVCS, which is Model-View-Controller-Service.  This is because you need somewhere to store your business logic.

Let’s break this down… bro.

The Model

The model layer is where you map everything that goes in the database into a class.  In Java, for example, Morphia can map Mongo documents into a class and give you properly strongly typed  implementations.

At the very basic level, this is the fundamental piece of every application, especially data-driven applications (which almost every application nowadays is).  I recommend whether starting to write a new application, or a new feature, when you start coding, start with the models.  This will give you a great starting point and help you to logically develop all of the following elements.

You should NEVER… EVER access the database directly using the model layer.  Did I ever say… EVER?  Thanks for not sucking!

What Belongs in a Model Class?

Lots and lots of properties.  You don’t want much more than getters and setters (of you need to define them), and methods that only need data from the current database record/document.

The View

This is the end goal, this is where we spit out the data we have in our models, BUT we should never EVER manipulate our models, in our views.  In fact, any operation that is not either meant to be spit out directly, or used in a conditional, increases your suicide rate by 20% and increases your death-by-angry-programmer chances by 50%.  You should never be addressing the service layer, nor should you be getting data in this layer.  You should only be using data passed to you directly from the controller.

Services

…are not in the typical “MVC” academic idealistic acronym, but really are likely the next most important piece of any application.  This is the foundational elements, the building blocks to building the rest of your application.

This should (if you had to pick one) is where the bulk of your code should be, and where nearly all of your business logic should go.  Access, organize, and play with your models here.

Controllers

This is what brings everything together.  The controller takes the data from the service layer, which does all the business logic for you, and determines the best way to give it to the views.  It parses the data to XML perhaps, JSON, etc.  No business logic should happen here, the only thing that should happen here is taking data form the service layer and sending it to the view.

Best Practices

There is still sone stuff I need to gripe about, but doesn’t fit in the areas outlines above, so I will complain here instead.

Strings Are EVIL

You know just how evil they are because I made evil red.  Use of strings (ESPECIALLY in strongly typed languages).

THe bottom line here, is use the proper object for the proper property.  If you are storing/using a date, then use the/a Date class.  If you are sting a number, use an int, double, float, long, or whatever is appropriate for what you are storing.  Stop using and passing arguments as strings.  It requires you use and convert strings back and forth and causes us to create and use business logic in the wrong places, and this is shear evil.

I could write about this one, but there are entire article written about this one:

http://blog.millermedeiros.com/trust-no-strings/

Don’t Repeat Yourself! (Keep your code DRY)

Read about this here: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Bottom line, if you copy and paste code, you are a horrible person.  Stop it and make a method, probably will be in the service layer.

Thanks.

More Resources

Here are some more good places to learn good programming practices.

http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer

Humor

When you eventually hate your life (and you will when you forget to use version control, or use sudo rm), you will need some humor.  Check out the oatmeal.  If you don’t have humor, you will die.

The end.