The code survival guide

Habits you should embrace

1.Stubbing

Stubbing is the process by which you first identify the functions, methods, classes, structures and files you will need to help solve the problem. You then code the framework of those pieces to fill in later with detail.

2.Use braces whenever possible

3.Refactoring

Refactoring is the process of taking existing code and rewriting it into a simpler, and often easier to maintain, form

4.Limit parameters to functions

Have you ever found yourself writing a function which takes in a lot of parameters? When I say a lot I mean upwards of 4, 5 or more? Taking in a lot of parameters to a function is usually a classic sign that the function you are writing is

going to be a complex one and might in fact be doing too much work. Each function should have a single task.

5.Knowing when to use an abstract class versus an interface

This question comes up a lot. When do you create an abstract class versus just implementing an interface? It will

always come down to your program’s design, but generally if you have some very dissimilar classes that may need to implement one or two similar methods maximum, go with an interface. Especially if those classes already exist in the system and are not easily inheritable. If the structure of the system calls for several classes that are quite similar then

go with an abstract class and inherit from it. Abstract classes are great in situations where you know you are going to have future classes based on the classes you are going to create.

For example, if you are working with a banking application that deals with the idea of an “Account” it is better to create that as an abstract class. This is because you know you are going to have various kinds of accounts at some point in the future. You may have some “No limit banking account” type and tying that into a system with abstract classes I find has the maximum flexibility. At some later point if you have a new type of account, all you have to do is inherit and add the extra functionality. But again there are no hard fast rules and often times using one method over the other is preferable based on the system requirements. Interfaces offer more of a “bolt on” way of adding additional code while abstract classes are more in line with extending existing class hierarchies. Now let’s say you had a banking account class, a mortgage class, a wire transfer class and all of them needed one method to return a balance, then an interface may be your best bet. All these classes are not really the same yet all need to be able to return some form of total balance value. Implementing an interface and adding it to each class will then allow you to add a getBalance() function to each without having to alter the classes too much in order to make them match up.

6.Incessant testing

I once heard a rule that said that 30% of your time should be coding and design while the other 70% should be for testing. I have seen different takes on this number but the one thing they have all shared was that the testing percentage was much higher than you may expect – typically over 50%. In short, follow the mantra “test test test!”

7.Pick a naming convention and be consistent with it

8.Reduce the number of calls to a function if it always results in the same answer

for(int i = 0;i < arr.length();i++){
//相当于对arr.length()调用了很多次
}
//应改为
int len = arr.length();
for(int i=0; i<len;i++){
//只调用了一次arr.length()
}

9.User flags where they make sense

10.Ask yourself “what if this happened”

Be curious,experiment

11.Use constants

Pitfalls to avoid

1.Long methods, especially in main()

hard to debug,hard to reuse

Your functions should be written in such a way that each function does one, and only one,

task. If you are putting more than roughly 20 or 30 lines of code in a function, then that is a

red flag that you might be doing too much. It may seem to be a bit overkill when you first

start out, but avoiding this pitfall is going to help you tremendously later.

2.Not commenting enough, commenting too much or too vague of comments

But as mentioned before, if you find yourself having to do a lot of explaining for a simple a +

b statement, it might be because the code is too complex or the motive is unclear. Review

the process to see if it can be rewritten in simpler and more readable ways.

3.Tight coupling

The reason we want loose coupling is to provide maximum reuse.

4.Variable letter abbreviations

5.Complex conditionals

6.Premature or incessant optimization

7.Reinventing the wheel

8.Using code you don’t understand

9.Acceptiong all the input a user gives “as is”

To avoid this pitfall, always validate the input coming into the system.

10.Thinking you are done when you are never really done

As the last pitfall of this document I wanted to cover one that many early programmers fall into. Thinking they are done when really the job of a programmer is never done. Sure you may not work on a piece of code for years, but if you work for a company the chances are you will end up revisiting that code one or many times later. Write your code so that when you do revisit it, you can make as much sense of it now as the day you wrote it. Software development is an iterative process and we are asked to maintain code that we have written and to add / remove features. Software grows and changes throughout time and that means we are never really done tinkering with it. Even if you leave the company, someone is probably going to end up picking up the torch and carrying it on into the future. Make it easy for them to do that. Never fall into the trap of thinking that you will never see your code again!