Have a strong work ethic.

There are a few simple keys to success, and many of them come from improving the right personal behaviors.

Always be professional. When people pay you good money they expect you to do a good job. You should be worth it.

Maintain a high level of productivity. Don’t slack off. Get things done.

Be a team player. You can’t be a force multiplier if you don’t support the people around you. Team players are worth far, far more than people who insist on working alone.

Be determined to succeed. Sometimes challenges are hard and the solution cannot be easily seen. Those people who keep going are the ones who find the solution.

Show consistent, high-quality work. This will lead to you having a reputation for success, and people will come to you for more work.

Method names should resemble the domain.

It’s always best to use business words to describe what a method is doing.

Don’t include words describing the logic in the method’s name. The logic should be hidden within the method implementation.

The method should look like a business person named it. It will be a lot more obvious to everyone what the purpose is.

data.fetchFirstPage

This is a clean and simple method name. The business person wants the first page of data.

data.selectOrderedRowsbyOrdinalColumn(20, "name")

This looks like gibberish. It may have more functionality, but it’s simply not clear at a glance what is really being requested here or why.

Try make life easier on yourself and on the next guy who has to support the code.

Methods shouldn’t depend on prior method calls.

You want your code to be more loosely coupled, so it doesn’t break later.

If you make two method calls on an object and the second call depends on the first call, then the first call should return a different class of object.

Why? Well if both calls worked on the same class, and you removed the first call, the code would break.

box.addShippingAddress(order)
box.addPostage

In this example, the addPostage method requires that the addShippingAddress method has been called. If you call addPostage without having a shipping address, it will fail. Yet, both of these are methods on box.

This might not seem like a big deal, but imagine if a lot of logic gets inserted in between the two methods. Then down the road as the code is being altered, the addShippingAddress method falls into a if/else tree and a case occurs where it doesn’t get called. It’s not hard to image the code getting to a state where the failure can occur, and it would take a while to track down the problem.

addressedBox = box.addShippingAddress(order)
stampedBox = addressedBox.addPostage

Now addPostage is only called on an addressedBox. The method won’t exist on a normal box. If you refactor the code and come to an error here, it will be because you don’t have the object you need. “addressedBox not found” or “no such method addPostage”. This makes it a lot more obvious what needs to be done.

The Law of Demeter

Chaining a series of methods together can increase dependencies on distant objects.

There are two ways to chain a series of methods together. One way is to break a complex method into smaller ones that can return the an object of the same class and thus continue to call methods without reaching outside of the class. This way, dependencies stay within the class. When methods change, the methods that depend on them are limited to the same class.

pizza = Pizza.newLarge.addExtraCheese.addTopping(Pepperoni).addTopping(Sausage).withCrispyCrust

On the other hand, if the methods in chain return different objects of different classes, then the chain creates dependencies on distant objects. This tight coupling creates problems because now the class has many more reasons to change.

candidate = pizza.shipmentAddress.city.mayor.party.leader

That’s far too much happening in one line. Why should the pizza class know how to find the party’s leader? If the Party class changes its method names, why should distant classes like Pizza need to be updated? Just because one *can* create amazing chains like this does not mean that one should.

The law of Demeter says you should only have one dot. This limits dependencies to one class away. It’s also related to the Single Responsibility Principle, in that a class that has to know the inner workings of distant classes simply knows too much.

The problem with the long chain of calls is that the code becomes brittle. Any change to any of the methods in the series could break the whole chain. If there is a change to the way the party’s leader is determined, why should that break the creation of a pizza shipment?

Said another way, you want to have your objects and methods loosely coupled. When you chain a lot of methods together, you become tightly coupled. Loosely coupled objects and relationships respond to change a lot better, making it far easier to improve later.

Finally although it’s called a “Law”, you should treat violations of the Law of Demeter as more of a code smell than an actual fault. There are times when chaining a couple methods together doesn’t cause a lot of harm. Just be aware that when you see the long chains, it’s a good opportunity to do some smart refactoring.

Don’t use conjunctions in method names.

Two great ideas taste great together, but not in a method.

Words like for, and, but, or, yet, so, etc can be used to extend ideas, qualify statements, apply filters, and other things. When you see these in a method name, it’s a sure sign the method is trying to do more than one thing.

A method should really only have one job, so when you see conjunctions, it’s a red flag that the previous developer piled too many things into one method. Try to refactor this into two or more methods.

Methods can then be chained together as needed. The individual, smaller methods will now be easier to re-use for other purposes. These new methods will also be easier to test.

Name booleans carefully.

Give them names that suggest a binary outcome.

When you’re using a boolean variable, you want to make it clear to the reader that this variable can only have one of two values: true or false. Names like “status” or “flag” are bad for booleans.

While “engineFunctioningStatus” may be stored as a boolean, using the word status seems to imply that there maybe several different possible values beyond true or false, such as “degraded” or “performance mode.”

A better boolean name would be something like “engineIsRunning.” It either is, or it isn’t. You want a name that strongly suggests a binary outcome.

Always use positive names. Having to figure out double negatives in your head quickly leads to bugs and errors. You would not want a boolean variable named “engineIsNotRunning.”

Other good examples include “fileIsFound”, “orderIsReadyForShipment”, “deliQueueEmpty”. Use words from the domain to clarify the meaning.

Variable names should describe what, not how.

Leave the how to the implementation.

Naming variables well is very important to creating code that can be easily maintained in the future. One key important thing to remember is that the name of the variable should reflect what the variable represents, in a business sense.

Some people make the mistake of using words that describe the technical implementation of the object instead. This often leads to vague names where the future reader is not sure what business object the variable is referring to.

Watch out for variable names that use computer terms instead of business words from the domain. For example, inputRecord, bitFlag, and calculatedValue. Yes, this is a record from the input stream, but what kind of record? A shipping record? A customer record? Wouldn’t have been clearer to say customerRecord instead?

And yes, a bit flag uses a bit and can be one or zero. Typically this indicates either a true/false or on/off condition. But this name doesn’t tell us either and gives us no clue what business thing is supposed to be true or false.

Similarly, a calculated value. We are writing programs here; they’re full of calculated values. What are we calculating? It’s a big mystery.

Take the mystery out of your code. Future you will appreciate it.

A variable should have one purpose.

Don’t overload variables into multiple meanings.

A variable should represent only one concept. It should be used for only one purpose. This seems obvious, but there three ways people go wrong with this.

First, some people will stuff multiple attributes into one variable. For example, imagine an object code of “DAL-4234-W”, where “DAL” represents location (Dallas?), “4234” is an object id, and “W” means the white model. That’s three separate pieces of information in one variable. Please don’t do this. Instead, create an object with three attributes.

myThing = new BusinessThing();
myThing.location = "Dallas";
myThing.id = 4234;
myThing.color = "white";

Not only is this a ton easier to read, it’s also immediately obvious what the component pieces represent.

The second problem people have is by adding hidden meanings. For example, say a variable normally has values between 1 and 200, representing something like length. But in this weird case, a -1 means an error code (couldn’t calculate length) and -2 means a different error (invalid permissions). Furthermore, a special code of 999 means this is a test object.

Magic numbers like these are really not obvious and can lead to trouble later if the attribute is used as input to a later process. Instead, put error codes elsewhere, or throw exceptions.

The third problem is that sometimes a variable will get re-used for a different purpose. This commonly happens with “temporary” variables. For example, maybe “i” means the count of packages at the top of the routine, but later in the routine “i” is used as a counter of shipping stations. Initially, it works, but when the code is altered later by someone else, the new developer is unaware of the re-use, and the scope of the variable changes enough to introduce bugs.

So avoid these problems by forcing variables to do only one thing. You can always make more variables; there’s plenty of room.

Look under the hood.

It pays to learn how things work under the covers.

The more you understand how the internal components work, the better you’ll be able to use high level abstractions built on top of them.

  • power, AC, DC, voltage regulators
  • bits, bytes, registers, machine code
  • binary representation, ints, floats, doubles, the mantissa, exponents, logarithms
  • stacks, compilers, filesystems
  • webservers, IP, TCP, proxies, process dispatchers
  • framework internals
  • web browsers, rendering, devices