Commenting in JavaScript

You're probably wondering why I chose this topic to write about, but it's funny how people get commenting so wrong while programming. Instead of explaining what or why their code does something, they give you a statement and expect you to figure out their code all on your own. That's wrong, isn't it? I mean, of course you're expected to analyze their code and find out what it does exactly, but when it comes to participating in huge projects, giving you an idea is a necessity - that's called working together.

Good Commenting

After a few times of doing it, you probably assumed that you got commenting down like a boss. And to be honest, I really don't blame you. All it requires is just a short summary of what that line of code (or block of code) does in your program. But it's how you explain it. Some people believe that they need to explain to the extreme just for you to understand what they had written, but that's not really the case. All you need is a nice, short sentence. Especially if someone knows how to program JavaScript. If someone didn't know however, that would be a different story (nosy buzzers).

Take a look at the picture above. The comment is short, clean and responsible for it's purpose. I didn't have to make multiple comments just to explain what my function does, because it honestly doesn't require that much explaining. Just summarizing it turned out to be efficient enough. Tips I advise are:

1. Explain as if you're telling someone your dream, only shorter.
2. Keep it short so that it won't flood the file with your multiple lines of comments.
3. Don't let your comment stretch out in the file so that people have to use the scroll bar to read it. 
4. Beautify your comments if necessary.
5. Always put your comments ABOVE your code. Never underneath it.

This isn't really something I expect for you to stress out over. In fact, it's not even necessary to. Commenting should be fun and powerful at the same time - you just have to do it right. But if you're doing it wrong and nobody understands a single line of your code (especially if it's complex), then you might want to erase what you created or either find another way to explain it correctly. 

Forever Alone with Code

As a short conclusion, don't write a block of code if you can't explain it. Not worth it.

Bad Commenting

Really?!

Sometimes programmers explain what their code does to the point that they're literally teaching you how to program for the first time. That's too far. That's like teaching a forty year old woman how to say a simple English greeting that she probably already knew..
Now, I'm not saying that all of us are smart when it comes to programming, but none of us are stupid either. Especially if we know how to program. hint, hint hint.

Bad comments are usually easy to distinguish from good ones; they don't provide much detail, they're way too long and possibly make absolutely no sense at all. As I mentioned above, summarizing is the key that leads to success. Not all of us are good at writing, but explaining what you did really shouldn't be that hard, unless it's an engine we're talking about - but not even that, because people also make documentations for their engines so that they're understandable, so that's not even a good excuse. Sorry!

Only the fittest will survive.

To avoid such annoyance and to perfect the obvious, practice. And when I mean practice, I mean practice. Every time you write a line of code that seems as if it's going to be complicated for others to understand, attempt to make a comment about it. This helps to see if you actually understood what wrote, so take your time and try giving it a shot.


Hope you guys enjoyed this post! Sorry for not posting earlier - I got caught up with a few things, so it's been a while. But please keep a look out for more posts by me! I'll be updating again shortly. :) 

Where to Code First

Whether it's being apart of an open-source project, soloing or partnering with friends, it's important that you know where to start first. Coding naturally starts anywhere, but it's best that you don't hop to different languages every time instead of focusing on one. This saying goes for all of the above that I just listed.

Open-source projects

Whenever you participate in open-source projects, you see each person (in that group) in a certain field; JavaScript Developers, Web Designers, Story Editors, etc. Everyone plays their part and doesn't worry about others unless it affects their area (For example, incorrect name of characters implemented by JavaScript Developers). This kind of process usually leads to success, because everyone informs the project leader whenever ideas come up or when confusion is put into play. The responsibility as a project leader is heavy, because you're expected to have some knowledge in at least one language or the other, especially if you don't have a co-leader to back you up. But you usually see Lead JavaScript Developer and such for a reason, because their job is to obtain the project leader's information and convert his/her words into coding-terms for other programmers (in that field) to understand. So let's say (as a project leader) you wanted random numbers to be generated and added each time it was displayed on screen - the Lead JavaScript Developer would have to take your information and explain to other programmers in a more programmable-sense. It's like converting one language into another. 

I suggest just a few tips for you when you enter open-source projects:

1. If you're really good in a particular language, try to keep your complex code at a lower level for people to understand. This is called consideration and team work.
2. Don't judge nor question the project leader's orders unless you intend to support his idea. The Lead JavaScript Developer usually does that.
3.  Look over your code before posting for others to see, because bugs will occur in the program if you don't. Tiny mistakes like miss of semicolons or wrong boo leans can cause major problems. 
4. If you can't participate, don't participate. It's a open-source project, not your lifetime career.

So, this leads back to the question: "Where do you code first?"

 For open-source projects - whatever field you're good in. 

Soloing on a project

                     photo is not me.

When you're by yourself, it's probably a good idea to be fully aware of what you do. The difference between being apart of an open-source project and soloing is that, you're the leader of the project. So you know what you want instead of being given orders by someone else. Acknowledging this fact is precisely a good idea when soloing on a project, so don't let that deprive you from coding what you please.

Tips that I suggest when soloing are:

1. Don't be afraid to talk to yourself when trying to solve some difficult problems. (troll) 
2. Take a break sometimes. Soloing is a lot for someone with one brain.
3. Never give up on a project you started. That's a major fault with programmers.
4. Ask for help. Having someone assist you won't lose the title as being a "solo project". Erase that pride.

Where should I code first? In my opinion, the HTML file. Designing the layout of your program is better than completing some code and then putting use to it afterwards. You want to see the result of your code fast, not slow. On top of that, creating a nice webpage/design is pretty hard, so it's best that you focus on that first. But make sure you utilize CSS - HTML doesn't look good without it.

Partnering with Friends

What could I possibly say to this? Take your time! You guys are friends. Of course, you want to have some kind of day picked out to work on the project with each other - but take your time. This topic is similar to open-source projects, so reading what I wrote above should be enough to understand what you should/not.

I have two tips that I'd like to suggest:

1. Drink Mountain Dew or Monster (Energy Drink)
2. Have fun and laugh

Where should you code first? Wherever your friends decide on. :)

I hope you guys enjoyed reading this - I had fun writing it! Learning one of the greatest importance is phenomenal in the programming world, so make sure you take this as a valuable lesson! Thanks again, and comment if you may!