Coding Principles

Principles

• Loose Coupling
• High Cohesion
• Change is Local
• It is Easy to Remove

Smells

• Rigidity ( A -> B -> C . something hardcoded in C )
• Fragility
• Immobility
• Viscosity of Design (Taking a shortcut and introducing technical debt requires less effort than doing it right.)
• Viscosity of Environment (skipping rigorous testing)
• Needless Complexity
• Needless Repetition
• Opacity

Class Design

• Single Responsibility Principle (SRP)
• Open Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Dependency Inversion Principle (DIP)
• Interface Segregation Principle (ISP)
• Classes Should be Small

General

• Follow Standard Conventions
• Keep It Simple Stupid
• Boy Scout Rule
• Avoid Multiple Languages in One Source File

Design

• Keep Configurable Data at High Levels
• Don’t Be Arbitrary (Have a reason for the way you structure your code)
• Be Precise

Dependencies

• Make Logical Dependencies Physical
• Singletons / Service Locator
• Base Classes Depending On Their Derivatives

Naming

• Choose Descriptive / Unambiguous Names (Names have to reflect the entire functionality)
• Standard Nomenclature Where Possible
• no Encodings in Names (No prefixes, no type/scope information)

Understandability

• maintain Consistency
• Use Explanatory Variables
• Prefer Dedicated Value Objects to Primitive Types (path type , instead of String , enclosing class)
• Poorly Written Comment
• Obscured Intent (Too dense algorithms that lose all expressiveness.)
• Obvious Behaviour Is Unimplemented
• Hidden Logical Dependency

Methods

• Methods Should Do One Thing
• Methods Should perform what is described by the name of the function.
• Avoid Method with Too Many Input Arguments
• Avoid Method with Too Many output Arguments (return object instead)
• Avoid Selector / Flag Arguments
• Avoid Inappropriate Static

Source Code Structure

• Variables and methods should be defined close to where they are used.
• Local variables should be declared just above their first usage ,depending on scope
• Nesting (should be more specific)
• Structure Code into Namespaces by Feature
• same feature together. Eg :A feature may use another feature; a business feature may use a core feature like logging

Useless Stuff

• Avoid Dead Comment, Code
• Avoid Clutter
• Inappropriate Information

Maintainability Killers

• Avoid Duplication
• Magic Numbers / Strings (Replace Magic Numbers and Strings with named constants)

Exception Handling

• Catch Specific Exceptions
• Catch Where You Can React in a Meaningful Way
• Use Exceptions instead of Return Codes or null
• Fail Fast
• Avoid Using Exceptions for Control Flow
• Avoid Swallowing Exceptions

view raw Coding Principles.md hosted with ❤ by GitHub