TL;DR notes from articles I read today.

The headers we don’t want

Some unnecessary HTTP headers you want to avoid:

• Vanity headers such as server, x-powered-by and via offer little value to end-users or developers but at worst they divulge sensitive information.
• Some headers, such as p3p, expires, x-frame-options and x-ua-compatible, represent deprecated standards.
• Headers that are only useful to debug data but are not recognized by any browser, such as x-cache, x-request-id, x-aspnet-version, x-amzn-requestID. As a developer, you may want to keep them on but know that removing them makes no difference to how your pages are rendered.
• x-robots-tag is a non-browser header only useful when the requesting agent is a crawler. 


Full post here, 7 mins read

These four ‘clean code’ tips will dramatically improve your engineering team’s productivity

Top strategies based on Robert Martin’s Clean Code:

• ‘If it isn’t tested, it’s broken’, so write lots of tests, especially unit tests. Code not covered by a test gets invisibly broken until customers spot the bug.
• Choose meaningful, short, precise names for variables, classes and functions and make it easy to find files by name. In case of conflict, choose precision over brevity.
• Keep classes and functions small - four lines per function and 100 lines per class at most - and make them obey the single responsibility principle. This will help with documenting code better as you will have lots of well-named sub-functions.
• Ensure functions have no side effects (such as modifying an input argument), and specify this explicitly in the function contracts if possible (such as passing in native types or objects that have no setters).

Full post here, 7 mins read

Principles of dependency injection

• Dependency injection can make your code more maintainable, using abstractions and by decoupling things.
• If you code to implementation, you will get a tightly coupled and inflexible system. Use abstractions and make your code be reusable and flexible.
• Follow the single responsibility principle and let each class do only one thing.
• Differentiate between creatables (which should be created within the constructor if the whole class uses them) and injectables (which should be asked for by the constructor and not created directly).
• Your constructors should only check for null, create creatables and store dependencies for later use. They should be free of any coding logic. 


Full post here, 4 mins read

Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().