## Seven ineffective coding habits of many programmers | Kevlin Henney

Here are the seven habits talked about by Kevlin Henney at Istanbul Tech Talks 2016.

1. How much of the code is actually communicating and how much is noise? Reduce code size and remove stuffs that doesn't add value.

2. Comments often make code noisy.
• Code should be as self explanatory as possible.
• Comments are the last thing people look at.
• If a programmer can't express himself in a programming language, he is less likely to be able to express himself in a natural language.

3. Sustainable spacing
• Lines should not go beyond 80 characters.
• Reading narrow columns from top to bottom is comfortable, like the newspapers.
• Developer might write code using large monitors, but someone reading the code might use any kind of device.
• Important information might reside at the rightmost region of the line.
• Code reviewers might use tablet.
• Narrow lines is universally suitable for most devices.
• Code should visually convey information. When things are aligned, people assume somehow they are related. So similar stuffs should be aligned.
• Positioning argument list
How not to: How to: Group arguments together, better readability Don't do this: Because this is unstable, alignment breaks when refactored. These are not prone to breaking alignment when refactored.
• Positioning curly braces
Don't do this: Visually unclear where the body of a block starts. Do this: Or this:

4. Naming should be simple, small, precise
• Reduce names with redundant information. Stop trying to dance around the name, just say the name.
Don't: Do:
• Meaningless words: Object, Thing, Component, Part, Manager, Entity, Item. How much of a name is left when you remove all of these words?
Example: Putting the word Exception behind every exception is bad. Because it is obvious that something that comes after a throws statement is obviously an exception. Exceptions that indicate something bad happening doesn't require the word exception in the end.
AccessViolationException $$\rightarrow$$ AccessViolation
IndexOutOfRangeException $$\rightarrow$$ IndexOutOfRange
InvalidOperationException $$\rightarrow$$ InvalidOperation
• Name exceptions using the problem so that it becomes obvious even without the word Exception.
ArgumentException $$\rightarrow$$ InvalidArgument

5. Missing abstraction: Code in the language of the domain.
Don't: Do:

6. Don't provide setters if only getters are needed. Getters don't necessarily need the word "get" because sometimes its redundant. Better: Getting something is an imperative statement in English which means having some kind of side effect.

7. The most important word in TDD is "driven". Are tests driving the development?