Question:
What are, if any, good 'habit'-s on programming a proper code?
Muhammad Ghazian
2015-12-28 08:57:34 UTC
I'm a (hopefully) thriving software engineer. I started getting (properly) involved on programming recently (about one and half years). I have read good articles on making your code a 'good' code (i.e. easy to read, robust, etc).

With all those programming language, surely there would be differences on how one achieve what so-called a 'good' code. That said, I would like to know your opinion on how to make oneself acquire good habits to make a 'good' code.

I would like to be able to progress on my project in a structured manner. So when it comes that time for me to return to my code, there won't be as much difficulty to come up with whatever I was doing back then.

*P.S. Sorry if the language is not well-written. It's late here :)
Five answers:
?
2015-12-28 09:53:47 UTC
Some of the following ideas are my opinion, but I find they're generally good ideas. In general, 'good habits' when programming are things that will potentially make your coworkers hate you less. As a counterpoint, all of the ideas here (and so far, they're ALL excellent ones) are not strictly necessary: you could write un-commented code, where everything is in one file, etc, etc, and your program would work. However, if you then ask your coworker Steve to work on your code, you're going to need to spend an inordinate amount of time teaching Steve what the heck your code does.

In general, here's what I do:

1) Comment your code. There's a bit of a balance here: you don't, for example, want to have the following:

var c = a + b;//adds a and b, stores in c.

because that's pretty obvious. However, let's say you're writing a particle system, and you have a variable "ppLS". You might do the following:

var ppLP=100;//per-particle life 'points', starting at 100.



2) SRP, or Single Responsibility Principal, also known as modularizing your code. Basically, this means separating your code into small bits. This has a number of benefits. Firstly, if you need to replace a bit of code, it's easier to find it. Second, you can have multiple resources pulling from the same file (so, for example, multiple parts of your site could pull from the authentication bits).



3) Name your variables, functions, etc. semantically. It's easy to get lazy and name your variables things like "a", "b" and "myVar", but what happens when you (or your coworkers) come back months later and try to edit the code? Are you going to remember what 'var a' does? Again, a bit of a balance here: don't go off the deep end and name your variable something like "var this_var_stores_the_users_first_name_so_we_can_say_hi", for example.

4) Finally, learn current trends! Learn what's popular, and what people are expecting you to use. Most stuff in coding becomes popular because people are like "Oh, wow, that's a really cool/useful way of doing X!".



EDIT: response:

For point 4, all I mean is you should read lots of current web development blogs and stuff. For example, in 2012, I believe AngularJS was quiet popular. Then eventually, it was followed by ReactJS, and now with the release of AngularJS 2, Angular's becoming more popular. So knowing what libraries, components, etc. are currently in vogue (and, moreover, WHY they are in vogue) will help you take advantage of these new tools.

For point 3, I'm not sure I can give you a specific set of guidelines, but I generally say that my variable names should be no more than two "words" (or two "words" and an abbreviation). For example:

var var1;//bad, no description

var lifeHP;//good, small and tells us what it's about

var particleLifeHitPointsForInvidualParticle;//bad, since the same idea can be represented, semantically, in a far shorter name.
Daniel B
2015-12-28 09:55:04 UTC
Here are some good ones...



- Use a consistent naming scheme for functions and variable and consistent code layout. There are a number of different popular scheme, but being consistent is more important then which one you choose.



- Do Not Repeat Yourself (DRY) - If you find yourself writing the same basic piece of code over and over in a program, pull it out into a function and call the function. For example if you need to read user information from a database, there should only every be one piece of code that does the actual read, that way if something changes in the User table you only need to fix one piece of code.



- The YAGNI (You Aren't Going To Need It) principle - Don't write code for something until you absolutely need it. We often get tempted to write code for something thinking that someone will eventually ask for it, but odds are if they ever do the requirement will have changed by that point anyway.



- Refactor your code - There is a tendency as you add features to program to just "tack them on" without going back and seeing how they relate to existing code in the program. You may find the a new feature can be added more cleanly if you modify something existing. The goal is to have the simplest possible code that get's the job done.



- Automated unit test - This support the refactoring habit. When you re-factor you risk breaking existing code, automated testing helps prevent that and thus makes refactoring safer.



- Use good, descriptive variable and function names. Other people have mentioned comments, but if you name things well and structure your code properly you reduce the need for comments. Comments are great when used properly, but they can be a double edged sword since you always have to remember to update the comment when you update the code. The code is truth, but the comments might not match the current truth.
Jeff P
2015-12-28 09:07:11 UTC
*Add comments, but not obvious comments. Comment the logic--not every other line of code.

*When available, always use object-oriented approach.

*Single responsibility principal--every module/class/component should have responsibility over a single part of the functionality of your application. This basically means break your code into individual chunks that have a single responsibility. You should not have code that operates a shopping cart combined with authenticating a user.

*Learn to use databases and APIs.
?
2015-12-28 10:56:38 UTC
Use lots of // comments. They are very helpful later when you come back and want to edit your code, so you know what everything is
CinesterStatic
2015-12-28 08:58:28 UTC
add comments

always save backup copies


This content was originally posted on Y! Answers, a Q&A website that shut down in 2021.
Loading...