# Good Programming Practices

* Use Meaningful Names and Avoid Made-Up Acronyms

// Avoid this
label1.text = dog.name
label2.text = dog.breed
label3.text = dog.int_temp
label4.text = dog.breed.int_fact

// Do this
name_label.text = dog.name
breed_label.text = dog.breed
internal_temperature_label.text = dog.internal_temperature
interesting_fact_label.text = dog.breed.interesting_fact

* Follow the programming language / project Conventions
* ### Functions
* If something is repeated twice anywhere in code make it a function.
* Keep Functions Short and to the Point. How short? around 20-25 lines or less.
* The function should fit entirely on your screen so that you don’t have to scroll to read it completely, if you have a large screen make the function fit 1/2 or 1/3 of your screen.
* Don't just break a large function in smaller ones, each individual small function should make sense in isolation.
* The function should do what the name PROMISED it would do.
* Update Member Variables Explicitly. If the function is part of business domain entity it's ok to update it's variables BUT if it is not then *return the changes* and *assign the values explicitly* to the member variable.
* always try using pure functions

    // this function doesnt mutate passed array, 
    // instead returns sorted array as a new array
    function sortArray(arr, compareFunction = null) 
    {
      return [...arr].sort(compareFunction)
    }

* Avoid Duplication.
* Before writing a new function to do something check if a function for that thing already exits.
* Keep common utlitiy function in a common project/class/file. eg. function for getting ip address for all interfaces OR function to encode a string to base64.
* If two or more functions do similar things with some common behaviour refactor them into a common function (but follow above function rules).
* Avoid Hard-Coded Strings and Magic Numbers.
* Every string should be a reference to a string resource, or a constant.
* Store common strings, enums, numbers used throughout project in their common files.
* Instead of using magic numbers make them constants or enums. eg.

    const float PI = 3.14159;
    const string SuccessfullyCompletedMessage = "Successfully Completed";

    // DO NOT DO THIS
    int connectionStatus = 0; // 0 is disconnected, 1 is connected

    // DO THIS
    enum ConnectionStatus
    {
        Connected,
        Disconnected
    }

- Define custom types for value objects. eg. for e-mail, geolocation (lat-long).

 class Email
 {
     Public string EmailId { get; private set; } 

     Email(string emailId)
     {
         VerifyEmailFormatCorrect(emailId);
         EmailId = emailId;
     }

     private VerifyEmailFormatCorrect(string emailId) 
     {
         // verify
         if (!verified)
         {
             throw EmailFormatException();
         }
     }

     public override bool Equals(object obj)
     {
         // check 
         return result;
     }
     public static bool operator !=(Email money1, Email money2)
     {
         // check
         return result;
     }
     public static bool operator ==(Email email1, Email email2)
     {
         // compare
         return result;
     }
 }

- Validate and check input/data from Unreliable Sources such as users or third party api's.
- Always Write Braces Around Single Line Blocks

## SOLID
### 1. Single-Responsibilty Principle
> Each and every class in your project should have one, and only one responsibility.

example:

# BAD
class Logger 
{
    string LogType { get; set; }
    
    public Logger(string logType) 
    {
        LogType = logType;
    }
    
    public log(string message)
    {
        if ( LogType == "console" ) 
        {
            Conosle.WriteLine(message);
        }
        else if( LogType == "file" )
        {
            File.write("logs.txt", message);
        }
    }
}

# GOOD

interface ILogger
{
    public void LogMessage(string message);
}

class EventTracker
{
    ILogger Logger { get; set; }
    
    public EventTracker(ILogger logger) 
    {
        Logger = logger;
    }
}

class ConsoleLogger : ILogger
{
    public void LogMessage(string message)
    {
        Console.WriteLine(message);
    }
}

class FileLogger : ILogger
{
    public void LogMessage(string message)
    {
        File.write("logs.txt", message);
    }
}

### 2. Open-Closed Principle
> Entities in your software system should be open for extension, but closed for modification.

### 3. Liskov Substitution Principle
> Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

### 4. Interface Segregation Principle
> Clients should not have to implement interfaces that they don’t use.

### 5. Dependency Inversion Principle
> High level modules should not depend on lower level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

- ## General
- Do peer code reviewing
- Refactor you written code daily. And/or assign a day in week to sit down and refactor all your weeks code.
- If you are making changes to some existing code Or adding

- ## Links to articles
-
* [good programming practices](https://x-team.com/blog/good-programming-practices-blog-post-wip/)
* [few simple rules to write good code](https://hackernoon.com/few-simple-rules-for-good-coding-my-15-years-experience-96cb29d4acd9)
* [The Single Responsibility Principle with C# Examples](https://www.intertech.com/Blog/the-single-responsibility-principle-with-c-examples/)
* [How to write SOLID code that doesn’t suck](https://medium.com/web-engineering-vox/how-to-write-solid-code-that-doesnt-suck-2a3416623d48)
* [solid principles in real world](http://blog.gauffin.org/2012/05/solid-principles-with-real-world-examples/)
* [how to write solid code that doesnt suck](https://medium.com/web-engineering-vox/how-to-write-solid-code-that-doesnt-suck-2a3416623d48)

Some <span style="color:blue">blue text</span>.