Happy Christmas!

It's that time of the year again, when light, once again, conquers darkness. Happy Christmas! :D

Object Oriented Programming for Scalability

I have encountered some projects before that were a bit old (around 10 years old). Naturally, years of patching and expansion has made it a bit large, and also a bit unmanageable because of its size. The sheer amount of code that I had to read through is fine. But the most annoying part is having to look for the locations of the functions. Where the hell are they located? That is the problem with functions that are not contained in neither namespaces or objects.

Namespaces and Classes give the element a certain locus by which it is identified with. This means, the larger the programs, the easier it is to identify where they would be found if you need to use them, or it just so happens that you need to maintain them.

Of course, OOP is just a tool. We do not have to code using an object-oriented paradigm. That is why there are still some code that are just simply hard to read through.

Imagine going through a few thousand lines in a source file, and trying to look for a function that was not defined there. You are left guessing where the function is in the mass of source files that you have. The header files that were included could provide a clue, but that is as far as helpful as they can get.

I am aware that there are search tools that could be used, but I do not think I would enjoy having to use the find function the whole time. I also use grep to look for functions. But I would not have to want to do that the whole time.

OOP is a great idea for programs that have large code bases. Abstraction allows you to modularize the implementation, thereby limiting the amount of damage that a coding error can make. You may also keep reusing code. This also implies something: You might want to leave using namespace out of your code and just get used to typing the std namespace. Well, maybe if you will not be using it too often. using namespace is also useful when libraries are collected into namespaces, and you will be using elements in the namespace very often.

I have stuck with OOP ever since I got the hang of it, and I will continue to use it to keep project maintainable. Happy coding, readers. :D

The importance of documentation

I have been working on a lot of code lately, and one sure thing that has kept me from progressing as fast as I want to is the fact that it lacks documentation.

Some people assume that their code is readable enough so that they do not have to write comments. While sometimes that may be true, sometimes it is not. What I would have given just so that the programmer would write a comment on what the function actually does so that I do not have to actually read the whole thing. I mean, if I had to read the code line by line, what happened to abstraction of code? Isn't that supposed to make programming easier by keeping me from having to care about how you implemented you function, just as long as I know what it does, what it needs (as parameters) and what it returns?

If the code is small, fine. Perhaps that is something forgivable because I would have time to know the code completely. But what if the project is around 50-100 files of source code long?

There are some programmers who even inadvertently just copy and paste the code, which means that sometimes they include code that is not used at all. Even if redundant code does not have anything to do with documentation, if someone had taken the time to document the code, then someone would have noticed that the function is quite useless in the context of the program, no?

Anyway, it has become my policy to at least explain at the top of my files what the code inside it really is. I tell them that this only includes the class prototype, and heck, I even put what the class does. Some people just write classes and they end up with misnomers that confuse the heck out of me.

If you write bad code, it is a given that I will dislike you. But if you write bad code AND even not have the courtesy of documentation, I will dislike you even more. Giving someone else badly written code and making them read it is just like writing a badly written story or essay and expect someone else to appreciate it.

So, kids, make sure that you write your code properly, and more importantly, never assume that the next person who will be working with your code has the time to read through your implementation. Write some comments: Explain it to them. Keep it clear and concise.

Hope you guys continue enjoying writing code.