Good practices when coding

Some good practices help when coding. If you include them in your routine, line after line, day after day, through little improvements, it becomes something usual.

I remember an algorithm’s teacher who used to say:

“Deliver code that just works is not enough, it should be elegant!”.

And that is true indeed! It doesn’t mean it should be perfect, but it means you should not deliver junk, that kind of code that as it grows or as the time passes turns into a nightmare for others or yourself: Difficult to understand, to maintain, to test, to reuse, etc.

I work with React Native, would like to share some of the good practices I try to use when I create Components, hooks or functions in order to avoid the problems above.

BUILD “FIRST” COMPONENTS

The “FIRST” acronym described by Addy Osmani mixes principles like KISS  and DRY, synthesizes the essence of a good component in a simple way.

When you’re trying to build a component, whether it’s visual or non-visual try to keep in mind five things:

Keep it Focused.
Keep it Independent.
Keep it Reusable.
Keep it Small.
Keep it Testable.

or in short, FIRST.Addy Osmani

TEST

I’ve already tasted how it is to build a production App having no automated tests, trust me it is not good at all. It may be hard to get used to writing tests in the beginning, but as soon as you realize the cost of performing manual tests only, you understand why:

Test code is just as important as production code!
Robert C. Martin

There are many types of tests, but I want to point four of them:

Static Tests: Check Typos and Type error while coding.

Unit Tests: Test if small part/unit of code work as expected.

Integration Tests: Test if a set of unit parts works together as expected.

End-To-End Tests: Test if the entire app works as expected, replicating the user behavior.

At least for now, I will work on the two firsts type of tests. The Static Tests are built-in in the TypeScript. The Unit Test will be writing according to the TDD – Test-Driven Development, using specific testing libraries (which I will write about in the next posts) to create automated tests.

Test-Driven Development is the practice of writing a test for functionality before you write the functionality itself. It follows the “Red-Green-Refactor Cycle:” first you write a failing test, then you write the minimum functionality to pass the test, then you rearrange the code if necessary to be simpler and clearer while still passing the test. Then the cycle begins again.https://learntdd.in/why-tdd

Check why to use TDD.

It looks like it takes more time to develop by following TDD, but It pays off in the end.

OTHERS

I encourage you dig deeper and look for best practices in programming. A good start point is the book “Clean Code”.

Clean Code

The book Clean Code by Robert C. Martin, compiles principles, patterns, and practices of writing clean code.

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.Clean Code by Robert C.Martin

I’ve found the Clean Code book summary bellow by Wojtek Lukaszuk. The same material is available as posters here, and you can find the files’ download link here.

SUMMARY

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

GENERAL RULES

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

DESIGN RULES

1. Keep configurable data at high levels.
2. Prefer polymorphism to if/else or switch/case.
3. Separate multi-threading code.
4. Prevent over-configurability.
5. Use dependency injection.
6. Follow Law of Demeter. A class should know only its direct dependencies.

UNDERSTANDABILITY TIPS

1. Be consistent. If you do something a certain way, do all similar things in the same way.
2. Use explanatory variables.
3. Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.
4. Prefer dedicated value objects to primitive type.
5. Avoid logical dependency. Don’t write methods which works correctly depending on something else in the same class.
6. Avoid negative conditionals.

NAMES RULES

1. Choose descriptive and unambiguous names.
2. Make meaningful distinction.
3. Use pronounceable names.
4. Use searchable names.
5. Replace magic numbers with named constants.
6. Avoid encodings. Don’t append prefixes or type information.

FUNCTIONS RULES

1. Small.
2. Do one thing.
3. Use descriptive names.
4. Prefer fewer arguments.
5. Have no side effects.
6. Don’t use flag arguments. Split method into several independent methods that can be called from the client without the flag.

COMMENTS RULES

1. Always try to explain yourself in code.
2. Don’t be redundant.
3. Don’t add obvious noise.
4. Don’t use closing brace comments.
5. Don’t comment out code. Just remove.
6. Use as explanation of intent.
7. Use as clarification of code.
8. Use as warning of consequences.

SOURCE CODE STRUCTURE

1. Separate concepts vertically.
2. Related code should appear vertically dense.
3. Declare variables close to their usage.
4. Dependent functions should be close.
5. Similar functions should be close.
6. Place functions in the downward direction.
7. Keep lines short.
8. Don’t use horizontal alignment.
9. Use white space to associate related things and disassociate weakly related.
10. Don’t break indentation.

OBJECTS AND DATA STRUCTURES

1. Hide internal structure.
2. Prefer data structures.
3. Avoid hybrids structures (half object and half data).
4. Should be small.
5. Do one thing.
6. Small number of instance variables.
7. Base class should know nothing about their derivatives.
8. Better to have many functions than to pass some code into a function to select a behavior.
9. Prefer non-static methods to static methods.

TESTS

1. One assert per test.
2. Readable.
3. Fast.
4. Independent.
5. Repeatable.

CODE SMELLS

1. Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.
2. Fragility. The software breaks in many places due to a single change.
3. Immobility. You cannot reuse parts of the code in other projects because of involved risks and high effort.
4. Needless Complexity.
5. Needless Repetition.
6. Opacity. The code is hard to understand.