6 things a Software Engineer/Developer should know to write production-level code
Software development is not just about using your coding skill to build something. Being a software developer means more than that, you are responsible for many things like the quality of the code. Whether your code is scalable or not, whether your code is understandable or not.
If you are someone who didn’t enter the professional world you might things how does it matter. But it matters a lot when you are writing a production-level code. I will explain to you everything in details.
Here are the 6 things that you should know being a software developer to write production-level code.
1. Write a meaningful name
Always give a meaningful name whenever you declare a variable or, create a function or class. Like if you are creating a function whose job is to add the two value then name it as “add”.
Why it is important?
The name reveals the intention of that variable, function or class. suppose I created a function of adding two number but named it “subtraction” or “rand_123”, by reading “subtraction” you will think the function’s job is to subtract two number and by reading “rand_123” you won’t understand anything about that function.
No one will open that function and understand the functionality of the code to understand what that function does. If other developers need to do this then it’s a bad approach to write a code.
Rules to follow:
- Avoid mental mapping: Use a name that could be understood by everyone. Others should understand the intention by reading the name.
- Class Name: Class name should always be a noun or noun phrase. From class, we create an object that’s why it should always be a noun phrase.
- Method/Function Name: Method name should be a verb or a verb phrase. A method/function is the one where the main functionality is implemented, these are the one which does the job. That’s the reason the verb phrase needs to be used to name a function/method.
- Searchable Name: Use a name that you can search for easily. It’s will benefit everyone, suppose you had to debug an issue in a particular function. But in a 1000s line of code how will you find that function. It will be time-consuming if you started reading each line. Searchable name is easy to remember and you can find the function in any IDE by find functionality of it.
- Don’t Pun: Avoid using the same word for two purposes. If you use the same name for multiple purposes then it will make confusion, which will impact the development process. Using the same term for two different ideas is essentially a pun.
- Use Solution Domain Name: The person who will read the code will be a programmer. So you can go ahead with CS terms, algorithm names etc. But if you do it for each name like this then it won’t be fair to the developer, as he/she has to run back and forth to the customer asking for the concept.
- Use Problem Domain Name: When there’s no programmer for what you are doing, use the problem domain name. At least another developer who maintains your code can ask the domain expert what it means.
2. Functions
Creating a function is not just about using writing your functionality. The function should be small and understandable for the developer who is reading your code. If the developer can’t understand the functionality within 3 minutes then it’s not good enough. You need to refactor it and make it small.
Why it’s important?
In today’s world, no one want’s to waste their time. The more you waste your time in understanding the code the delay in delivering the product to the client.
Also, it makes it easy to debug and reuse the function again and again. You may know the basic of programming that you should never repeat the code.
Rules to follow:
- Small: The function should be small enough to fit the screen. Which is about 20–30 lines of code. There are so many variations in screen size, so considering all type 20–30 lines of code will be a sweet spot to consider the length of the function.
- Blocks and Indenting: I have seen people who don’t give block-wise indentation. It makes it hard for other developers to read the code. Where the block start and where it ends. Making a block-wise indentation makes it a lot easy to read in fact it will also make you easy to debug (Especially if it’s a syntax error).
- Do one thing: Functions should do one thing. They should do it well and should do it only. The purpose of a function is that does only one thing. If your function has multiple sections with different functionality then create a separate function for that section’s functionality and call that function.
- Switch statement: If you are a switch/if statement then tries to replace it with polymorphism. You will know the concept of polymorphism from object-oriented programming. You can create multiple methods by overriding or overloading.
- Function arguments: Lesser the arguments better it is. If possible pass only 1 argument in the function. At max pass 3 arguments if you need to pass more than that then pass those value as an object or single arguments of the list.
- Command query separation: Function should either do something or answer something but not both. As mentioned in the previous point function should do only one thing only. Similarly, a function should either change the state of the object to return some information about the object.
How to write a better function?
- Restructure/Refactor
- Make function small
- The function should do one thing only
- Less argument in a function
3. Comments
Try to avoid using comments as much as possible. Comments are a sign of bad code. Make the code organised so that comments are not required to explain the functionality. Express yourself in the code.
Comments are not always bad to use so u have to know when it’s good and when it’s bad to use.
Good Comments:
- Legal Comment: Copyright and authorship statements are necessary are reasonable things to put into a comment at the start of each source file.
- Informative Comments: It’s sometimes useful to provide basic information with a comment. For example what date format needs to be sent in the function.
- Explanation of Intent: Sometimes you need to explain why you used a particular logic or condition. That time you can add a small explanation comment (1 line comment).
- Clarification: Sometimes it’s helpful to translate the meaning of some obscure argument or return value into something readable.
- TODO Comments: It’s reasonable to leave “To do” notes in the form of //TODO comments. The TODO comments explain why the function has a degenerate implementation and what the function’s future should be.
Bad Comments:
- Redundant Comments: If there are too many comments in your code. Then the comment probably takes longer to read than the code and is completely redundant.
- Noise Comments: Comments that’s useless and provide no new information about the code.
- Journal Comments: Some people keep a journal whenever they edit a code. Earlier it was useful but nowadays we have a version control system to keep a track of it.
- Comment-out code: Keeping a commented code is a bad thing to do. You may think it will be easy to revert the code. But keep a note that when making a production release these commented codes should be removed. There is no point in keeping that commented once the production release is planned.
- Too much information: Don’t keep irrelevant information in comments as it is useless and take extra storage space.
You may get an idea of good and bad comments, when you can use comments and when not.
4. Objects and Data Structure
There is a reason that we keep our variables private. We don’t want anyone else to depend on them. We want to keep the freedom to change their type or implementation on a whim or an impulse.
Why do the programmers automatically add getters and setters to their objects, exposing their private variables as if they were public?
Data Abstraction
You might have heard of this term in object-oriented programming. what does it mean? It means that keeping the data and the functionality private. No one can outside the object will know the functionality of that object. This is the reason why mainly use objects.
The Law of Demeter
The Law of Demeter says that a module should know about the innards of the objects it manipulates. The objects should not expose their internal structure through accessors because to do so is to expose, rather than to hide, its internal structure.
More precisely the Law of Demeter says that a method f of class C should only call the methods of these:
- C
- An object created by f
- An object passed as an argument to f
- An object held in an variable of C
From:
objectA.getObjectB().doSomething();
To:
objectB = objectA.getObjectB();
objectB.doSomething();
Data Transfer Objects
A Data Transfer Object is an object that is used to encapsulate data, and send it from one subsystem of an application to another. DTOs are most commonly used by the Services layer in an N-Tier application to transfer data between layers.
5. Error Handling
Error handling is the most important thing that needs to be done while you are writing a production-level code. We always make a log of errors if due to some reason something goes wrong we can debug it easily. But error handling also has some rules that we should follow.
Rules to follow:
- Use expressions rather than return code: Many people just send error code in response. But to understand the error-code developer need to read check the meaning of that error code. Instead of sending an error code pass message that was the error. It will easy to understand.
- Write your Try-Catch-Finally statement first: Whenever you are creating a new function first write the Try-Catch-Finally statement. It’s the topmost priority thing to do before doing implementing the functionality.
- Define exception classes in terms of a caller’s needs: There may be a different type of error like validation error, programming error or something else. Define the error throw that based on the error type.
- Don’t return null: Suppose you created a function and your primary condition checks if the argument is not null, but if the argument is null then you return null. Instead of returning null value return NullPointerException.
- Don’t pass null: Never pass null in a function unless the function expects you to pass null. It’s better to avoid this scenario as much as possible.
6. Classes
A Class in object-oriented programming is a blueprint or prototype that defines the variables and the methods (functions). An object in OOPS is a specimen of a class. Software objects are often used to model real-world objects you find in everyday life.
Classes should be small
For class size, we measure by counting the number of responsibilities. More responsibilities larger the size of the class.
Note: We should be able to write a brief description of the class in about 25 words without using the word “if”, “and”, “or” or “but”.
- The Single Repository Principle: The SRP states that a class or module should have one and only one, reason to change.
- Cohesion: Class should have a small number of instance variables. Each of the methods of a class should manipulate one or more variable. In general, the more variables a method manipulates the more cohesive that method is to its class.
Organising the Change
Most of the time changes are continual. Every change subjects us to the risk that the remainder of the system no longer works the same way as intended.
To organise the change we can isolate the changes. By isolating the changes I mean make reduce the dependency as much as possible. Make a decoupled system, so that one change in one module doesn't impact another module.
These are the 6 basic things that a software engineer/developer should know taken from the book Clean Code by Robert C. Martin. You can learn a more advanced topic like Unit Test, Concurrency, Refactoring, Code Smell etc in this book.
