poltinsights.blogg.se - Clean code pdf github

CLEAN CODE PDF GITHUB REGISTRATION

The law of Demeter: Object should only communicate with other objects in their neighbourhood.Both ways have advantages/disadvantages, so choose dependent on your situation.Hard to add new kinds of data structures.Easy to add new behaviours to existing data structures.Data structures expose their data and have no meaningful functions.Hard to add new behaviours to existing objects.Objects hide their data behind abstractions and expose functions that operate on that data.Create abstract interfaces so that one can manipulate the essence of the data without having to know its implementation.Avoid manipulating directly public variables.Insert blank characters between math equations and function arguments to increase readability.

Set a horizontal limit of 80-120 characters.

A function that is called should be below a function that does the calling.

that are connected should be in neighbourhood

Insert blank lines between functions to increase readability.

The Newspaper Metaphor: Top (high level concepts), bottom (detailled implementations).

Avoid files that have more than 500 lines of code (recommendation: 200 lines).

All other comments should be deleted (javadoc headers, closing brace comments, commented out code.

Legal comments: Copyright, regex explanations, explanations of unobvious code structures, todo, warnings.

Always try to avoid comments and express yourself in code.

Code is always bad at the beginning: Refactoring always needs to be done afterwards.

Structured Programming: Every function should have one entry and one exit (one return, no break/continue/goto statements) only makes sense in big sized functions (which should also be avoided).

"DRY": Don't Repeat Yourself: Avoid duplication of logic/code and make functions with common behaviour.

Extract try/catch structures outside of functions.

Do not use boolean/flag arguments (the function then does more than one thing!).

Function arguments: 0 (niladic, best), 1 (monoadic, OK), 2 (dyadic, OK), 3 or more (polyadic, should always be avoided).

Stepdown Rule: Programs should always be readable from TOP TO BOTTOM (functions used are always declared after and not before).

Don't use output arguments (instead of appendFooter(html) use html.appendFooter()).

CLEAN CODE PDF GITHUB REGISTRATION

registration that (unexpectetly) sets automatically sessions/cookies Avoid functions with side effects: E.g.Should follow the "Open-Closed-Principle": Modules should be open for extensions and closed for modifications.Classes always should follow the "Single-Responsibility-Principle": Class should only one thing.Should always have one level of abstraction.Should always do one main thing (you can describe that "thing" in one meaningful sentence).Should not be longer than 5 lines of code.Functions should use verbs ("deletePage") or should be prefixed with set/get ("getName").Classes should be nouns ("Customer", "Account").don't use "GSTzip", "GSTlocation", "GSTstreet", "GSTnumber" inside a class "GST") Be consistent (always use one of fetch/retrieve/get in different classes).Use searchable names ("realDaysPerDay" vs "d").Use pronounceable names ("generationTimestamp" vs "genymdhms").Use intention-revealing names ("elapsedTimeInDays" vs.

The Boy Scout Rule: Leave the campground cleaner than you found it ("always refactor a little bit every time you work on your code").