Quotes About Code organization

Are the individual functions in your modules too large? This is not so much a matter of line count as it is of internal complexity. If you can't informally describe a function's contract with its callers in one line, the function is probably too large.9 9 Many years ago, I learned from Kernighan & Plauger's The Elements of Programming Style a useful rule. Write that one-line comment immediately after the prototype of your function. For every function, without exception.

When classes lose cohesion, split them!

it's confusing to have a controller and a manager and a driver in the same code base. What is the essential difference between a DeviceManager and a Protocol-Controller? Why are both not controllers or both not managers? Are they both Drivers really? The name leads you to expect two objects that have very different type as well as having different classes. A consistent lexicon is a great boon to the programmers who must use your code.

But then closely related concepts should not be separated into different files unless you have a very good reason. Indeed, this is one of the reasons that protected variables should be avoided.

But while you can always write 'spaghetti code' in a procedural language, object-oriented languages used poorly can add meatballs to your spaghetti.

The DRY principle tells us to keep the low-level knowledge in the code, where it belongs, and reserve the comments for other, high-level explanations.

When you link to multiple JavaScript files from your page, all the global variables are defined in the same global space.

If a class contains more than about seven data members, consider whether the class should be decomposed into multiple smaller classes (Riel 1996). You might err more toward the high end of 7±2 if the data members are primitive data types like integers and strings, more toward the lower end of 7±2 if the data members are complex objects.

Avoid duplicate code. Undoubtedly the most popular reason for creating a routine is to avoid duplicate code. Indeed, creation of similar code in two routines implies an error in decomposition. Pull the duplicate code from both routines, put a generic version of the common code into a base class, and then move the two specialized routines into subclasses.

once gotos are introduced, they spread through the code like termites through a rotting house.

Don't differentiate routine names solely by number. One developer wrote all his code in one big function. Then he took every 15 lines and created functions named Part1, Part2, and so on. After that, he created one high-level function that called each part.

Blueprints were introduced in Chapter 7 as a way to define routes in the global scope after the creation of the application was moved into a factory function. The routes related to the user authentication system can be added to a auth blueprint. Using different blueprints for different sets of application functionality is a great way to keep the code neatly organized.

Instead of commenting sections in long functions, extract smaller functions whose names capture the former sections' intent.

In a sense, a module is like a single-instance class, without inheritance, which corresponds to an entire file of code.

That is, a class is a local scope and has access to enclosing local scopes, but it does not serve as an enclosing local scope to further nested code.

everything is a "first class" object in Python —

Parallel inheritance hierarchies is really a special case of shotgun surgery. In this case, every time you make a subclass of one class, you also have to make a subclass of another.

If you have to spend effort looking at a fragment of code and figuring out what it's doing, then you should extract it into a function and name the function after the "what".

Encapsulation is important, but the reason why it is important is more important. Encapsulation helps us reason about our code.