Any experienced programmer has his agenda of “I wish I knew this”.
I want to share with you my agenda.
Version control
That’s the first aspect that comes into my mind.
I’ve looked at code I wrote before 2010 — as a kid and a totally amatuer — I had
all kind of files/folders lying around with “Ver1”, “ver2”, etc…
As a beginner i’d definitely advise myself to learn a version control tool.
Team work
That’s something I couldn’t learn on myself of course.
However today the collaboration with others is easier — Github, Discord, Slack, etc…
Go there, speak up, ask questions, show yourself.
Learning to co-op with people and collaborate on the same code is meaningful and will make you better as a programmer
and better as a team member.
If you want to reach quickly, go alone. If you want to reach far, go together.
Single responsibility
Talking about SOLID principles I think the most important one is single responsibility, Because:
It forces you to split into different files and maintain one responsibility at a time.
This is VERY helpful when solving bugs.
When you try to find bugs in a 6K lines file you have a hard time trying to wrap around it.
The alternative is to split into different files — so if a code has a bug in it you know where it is and what component related to it.
Coupling and Cohesion
Coupling- The degree an entity is “Connected” to another component.
Cohesion — The degree an entity is correlated to another component.
You want your API to be — low on coupling and high on cohesion.
High coupling
public class FruitSlicer {} public class B
{
private FruitSlicer mSlicer;
}
Low coupling
public interface ISlicer {}
public class B
{
private ISlicer mSlicer;
}The high coupling means that B is composed of the details — a fruit slicer.
If we need another kind of slicer we’ll need to manually add it, cast it or replace it which activly introduces changes into the class.
Interfaces are more abstract and easy to implement and recompose — if we implement a FruitSlicer, MeatSlicer or anything else, it’s easy to replace.
Thus comes into the agenda one more guidelines:
Program to interfaces, not classes.
High Cohesion
public interface ILogger
{
void Info(string message);
void Debug(string message);
void Error(string message);
}The API defines strict methods of writing different levels of logging — thus the high cohesion between them.
They all responsible on the level of the log message.
Low cohesion
public interface ILogManager
{
void Info(string message);
void SaveToFile(string path);
void SendTo(string ip);
}Managers are sort of an anti-pattern and should be used with caution.
Here we have 3 responsibilities: Writing logs, save the log into a file or sending it to an IP.
Maybe they are all corellate to “Logging” but the reponsibility here is wide — IO with file, networking AND logging managment.
True meaning of “Oriented programming”
I read all kind of tutorials and guides on “Object oriented programming” but I never understood the *True* meaning.
Oritentency means that our most *basic* building block is defined as something.
Function oriented programming has it’s basic building block as Functions!
Object oriented programming has it’s basic building block as Objects!
Data oriented programming? Data!
You get the pattern.
So what’s the meaning?
Let’s design a small alram system for a house because it’s easy to imagine the physical components as objects.
If we design it with OOP in mind, we use an object as a basic building block.
What is an object? An entity with state and behavior.
Some objects may be data only — then we call themo models.
Some objects may be behavior only — then we call them services.
Let’s start with composing a controller:
public interface IAlarmController
{
void TurnOn();
void TurnOn(IEnumerable<Location>);
void TurnOff();
void TurnOff(IEnumerable<Location>);
event Action<Location,TimeStamp> AlarmOn;
}A controller has usually the control panel and holds information, so stuff like:
- Cnc (Command and control)
- Alerts
- Registered locations
- Menu for adding/removing.
A location is a physical place where we have sensors for detecting anomalies.
public class Location
{
private IList<ISensor> mSensors;
public string Name { get; set; }
public GUID Id { get; set; }
}A sensor is a physical device that can generate a report,
If we look at what kind of sensors we want:
ISensor
→HeatSensor
→MovementSensor
→LightSensor
→MotorSensor
etc…
I hope this simple example helped.
Don’t be a coding Ninja
Don’t:
var stringified = (isFlag? mResults[“Yes”].Active? “The result is active” : “The result is not active” : mResults[“No”].Active? “Active result is denied” : “Request denied”);Do:
var result = isFlag? mResult["Yes"] : mResults["No"];
var isActive = mResults.Active;
if(isFlag && isActive)
{
return "The result is active";
}
else if(isFlag && !isActive)
{
return "The result is not active";
}
else if(!isFlag && isActive)
{
return "Active result is denied");
}
else if(!isFlag && !isActive)
{
return "Request denied";
}That’s not the best example, but proves my point.
After I’ve written my first example It took me some time to grasp what I was trying to achieve.
Sometimes — even our ninja code is hard for us to understand, so simplify it even though it looks more dumb. (Just imagine having to fix bugs in such code, yikes)
Think first, design and only then construct
It’s easier to erase a class from a sheet of paper than to reconstruct the code
I was teaching this guy how to start a software project.
I asked him to use Word or any other tool to design the software first and then open visual studio and write the code.
Of course he wasn’t able to do it, after some time he just told me “I can’t, I need the VS”, So I allowed him to write some code.
The conclusion is — junior developers are so caught up with details they forgot to think first on what they need to craft.
Sometimes it’s not their fault — they don’t know the API.
For that I have a solution with 30 different projects that most of them labeled “TestX” , “ConsolpeApp”, etc…
If you aren’t sure of the API it’s ok to use a simple project to test few lines of code -
But never use it to write the whole code just to test it.
Always design your code before you construct it.
— — — — — — — — — — — — — — — — — — — — — — — — — — ——
This isn’t a complete guide for beginners.
Just some points I think would boost me if I knew them at the beginning.
Hopefully, it would help someone to get better!
