\$10

### Image of the Day Submit

IOTD | Top Screenshots

## Programming the right way?

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

23 replies to this topic

### #1Nodime  Members

Posted 17 July 2013 - 11:05 AM

Greetings all,

This is my first post here, and I suppose the write place to be asking,

I've been programming for several years but I would describe myself as a hack and slash programmer, with buggy code and not very well written.

Can anyone point me in the right direction to coding the right way with less bugs and more reliability?

My preferred learning platform is visual and audio

I mainly program in vb6 and vb.net but am currently learning c++ I don't know if the proper technique can be applied across all languages or whether there is a proper way to do each one?

Any help/links would be greatly appreciated.

Thanks

Richard

### #2tharealjohn  Members

Posted 17 July 2013 - 12:45 PM

POPULAR

Hey Richard,

I always like these kinds of questions, and I ask it about myself all the time. For me, the best way to gain the information you are looking for was to work with/learn from other more experienced developers and see what they do. I also browse code on projects that are more "mature" and have industry experienced professionals writing it. Take a look at some major open source projects in the language of your choice. You may be able to pick up some patterns and ideas that make you say "Oh, I wouldnt have thought to do it this way". It might also help you if when you feel you have some problem code to post it here and ask for input. I have seen many devs on here give some valuable feedback on how to organize or refactor things.

Sorry I don't have any books or visual aids that have helped me. =(

Generally though, books on software architecture and "best programming practices" type articles would be something to look for.

Good Luck!

Edited by tharealjohn, 17 July 2013 - 12:45 PM.

jmillerdev.com

### #3Nodime  Members

Posted 17 July 2013 - 01:39 PM

I hadn't really considered looking over peoples source code, but I will definitely start having a nosy at other open source projects and how they are built.

### #4IcedCrow  Members

Posted 17 July 2013 - 01:42 PM

To me it comes down to working on projects and meeting your objectives.  Experience is the first thing.

After that I'd suggest looking up books on clean code.  I learned a lot from working with people that had worked a lot in the business and every place I've worked at I have had the opportunity to learn even more.

Hit up amazon for "Clean Code".  There should be a book with that title, and its pretty good IMO.  Goes over some things that people do all the time that contribute to the downfall of their own code.

For more on my wargaming title check out my dev blog at http://baelsoubliette.wordpress.com/

### #5Álvaro  Members

Posted 17 July 2013 - 01:57 PM

Hit up amazon for "Clean Code". There should be a book with that title, and its pretty good IMO.

That book it is a bit extreme. For instance, they advocate that each function should do only one thing, so you shouldn't write code like this:

void compute_salary() {
double result = 0.0;
try {
result += compute_base_salary();
result += compute_bonus();
}
catch (...) {
complain("Problem computing salary: Returning 0.");
return 0.0;
}
return result;
}

The reason is that this function does two things: Exception handling and computing something. The book advocates placing a single function call in the try' block, so that this function's only purpose is exception handling. Unfortunately, I find myself struggling to find a good name for such a function (compute_salary_without_exception_handling'?), which is my primary guide as to whether something should be in its own function.

But it is still a good read, and it will make you think about many interesting issues.

### #6NightCreature83  Members

Posted 18 July 2013 - 03:49 AM

I found looking at other peoples code helped a lot but also looking at my old code that I wrote years ago and spotting the mistakes in them. This will also give you a sense of growth as a programmer in that you get to see what you are doing better now.

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, theHunter, theHunter: Primal, Mad Max

### #7Telastyn  Members

Posted 18 July 2013 - 04:59 AM

Can anyone point me in the right direction to coding the right way with less bugs and more reliability?

First things first, there's no "right" way - there are a bunch of ways that will get the job done well.

Beyond that, I would look at the code you have written, and figure out why there are bugs. Did you use certain patterns that made the code fragile? Did you name things poorly so they got misused? Did the functions have too many side effects? Did you not have a good process to prevent typos/merge errors/etc?

Books and even good programmers can only bring you so far. Eventually you have to internalize the knowledge so that you can get the feel of what things are troublesome and why; what things are usually good and why. Then you can better apply those things to the problems at hand.

### #8MarekKnows.com  Members

Posted 18 July 2013 - 11:18 AM

For C++ programming I highly recommend checking out Scott's "Effective" books: http://www.aristeia.com/books.html

They are a great resource and point out common techniques that everyone should use.

---
Free C++, OpenGL, and Game Development Video Tutorials @
www.MarekKnows.com
Play my free games: Ghost Toast, Zing, Jewel Thief

### #9tufflax  Members

Posted 18 July 2013 - 02:06 PM

This is in my opinion the best resource ever on this topic: http://www.infoq.com/presentations/Simple-Made-Easy

Also, you might wanna read this: https://sites.google.com/site/steveyegge2/being-the-averagest (and maybe this, this is where the name of the other article comes from: http://www.paulgraham.com/avg.html)

Edited by tufflax, 18 July 2013 - 02:14 PM.

### #10Khaiy  Members

Posted 18 July 2013 - 07:01 PM

I'm always happy to point people to Code Complete (2nd ed.). It's got lots of great language-agnostic information and is easy to use as a reference. But as others have said, it's only through experience that you improve at coding.

-------R.I.P.-------

Selective Quote

~Too Late - Too Soon~

### #11EddieV223  Members

Posted 18 July 2013 - 11:02 PM

I'm always happy to point people to Code Complete (2nd ed.). It's got lots of great language-agnostic information and is easy to use as a reference. But as others have said, it's only through experience that you improve at coding.

+ rep for you, I was about to recommend that same book.  It really is "the" book about how write quality code.  Just a short 960 pages of line after line great advice.  I took notes while reading this book, the notes were on a large white board I keep on the wall by my computer, they've been there for a year, I know them by heart now but I can't bring myself to erase them.

If this post or signature was helpful and/or constructive please give rep.

// C++ Video tutorials

// Easy to learn 2D Game Library c++

SFML2.2 Tutorials http://www.sfml-dev.org/tutorials/2.2/

// Excellent 2d physics library Box2D

// SFML 2 book

### #12warnexus  Prime Members

Posted 21 July 2013 - 07:41 AM

1) Design before writing code

2) Refactor duplicated code

3) Make sure the code is short and straightforward

When you write code, make sure the other person can understand it without comments

Well-written code are straightforward

### #13EarthBanana  GDNet+

Posted 21 July 2013 - 07:28 PM

here is a little tip i just caught myself in - don't use random numbers in your code - give the number a variable name somewhere..

i just found a line in my code that said if ( pos.x * 1.27f <= 23.45f )

this took me like an hour to figure out why i wrote that

### #14Epricity  Members

Posted 21 July 2013 - 09:01 PM

I think the thing that's most important when writing any program is thinking about maintainability before you start writing it.

No matter what framework, or tools you decide to use, you should always break the functionality of your program into organized pieces, so that you always know where to look if you're extending, or if something breaks.

You can use patterns like MVC for this, or you can create your own.

As long as you understand how your app is built without having to dig for anything, you're in good shape.

### #15Infinity95  Members

Posted 22 July 2013 - 01:02 AM

here is a little tip i just caught myself in - don't use random numbers in your code - give the number a variable name somewhere..

i just found a line in my code that said if ( pos.x * 1.27f <= 23.45f )

this took me like an hour to figure out why i wrote that

Or you could save some time and just write in a comment on the same line what the numbers are about. Then you don't have useless variables that could get you confused.

"Errare humanum est, sed in errare perseverare diabolicum."

### #16Khaiy  Members

Posted 22 July 2013 - 06:37 PM

here is a little tip i just caught myself in - don't use random numbers in your code - give the number a variable name somewhere..

i just found a line in my code that said if ( pos.x * 1.27f <= 23.45f )

this took me like an hour to figure out why i wrote that

Or you could save some time and just write in a comment on the same line what the numbers are about. Then you don't have useless variables that could get you confused.

It takes no more time to declare a well-named variable than it does to write in a comment explaining a number, and a well-named variable shouldn't be confusing. Using magic numbers is a terrible habit. I'm sure there are situations where the approach you describe is appropriate, but advocating it as a rule sounds to me like saying that doing cocaine is fine as long as you go jogging afterwards because jogging is healthy, right? It's focusing on the wrong end of the problem.

-------R.I.P.-------

Selective Quote

~Too Late - Too Soon~

### #17Infinity95  Members

Posted 23 July 2013 - 02:25 AM

here is a little tip i just caught myself in - don't use random numbers in your code - give the number a variable name somewhere..

i just found a line in my code that said if ( pos.x * 1.27f <= 23.45f )

this took me like an hour to figure out why i wrote that

Or you could save some time and just write in a comment on the same line what the numbers are about. Then you don't have useless variables that could get you confused.

It takes no more time to declare a well-named variable than it does to write in a comment explaining a number, and a well-named variable shouldn't be confusing. Using magic numbers is a terrible habit. I'm sure there are situations where the approach you describe is appropriate, but advocating it as a rule sounds to me like saying that doing cocaine is fine as long as you go jogging afterwards because jogging is healthy, right? It's focusing on the wrong end of the problem.

I never said it should be a rule. Just my opinion. I don't like it when i have variables that are only used once just for the sake of knowing what they are used for. That's what comments are for. If i use them more than once i almost always use variables for them because it's easier to change the value of it. I only have to change one value and not find and replace 3 values. But if the value is only used once in the whole program why not just write it in there and make a small comment. I know it's preference but still i don't like it when there are 'unnecessary' variables.

"Errare humanum est, sed in errare perseverare diabolicum."

### #18Godmil  Members

Posted 23 July 2013 - 01:49 PM

I'm quite new to programming (c++) and I've been trying to make sure I'm learning good techniques. A lot of things I'm reading is to avoid older ways of doing things. Like you should be using containers such as Vector instead of Arrays, trying to avoid pointers, and if you use a lot of New/Delete's then it's worth reading about RAII.

### #19Khaiy  Members

Posted 23 July 2013 - 02:25 PM

I never said it should be a rule. Just my opinion. I don't like it when i have variables that are only used once just for the sake of knowing what they are used for. That's what comments are for. If i use them more than once i almost always use variables for them because it's easier to change the value of it. I only have to change one value and not find and replace 3 values. But if the value is only used once in the whole program why not just write it in there and make a small comment. I know it's preference but still i don't like it when there are 'unnecessary' variables.

As I said, there are bound to be cases where your preference here is the best choice. But in practical terms, as I also said, declaring a variable with a good name takes no more time than writing a comment, and a well-named variable should be equally clear about its purpose as well as more concise and more convenient for code maintenance.

It will normally be true that a number, used only once and only in a function's local scope, can be similarly well represented by a plain integer/float/double/whatever or a named variable. But it is less convenient and less natural for a programmer to refer to a comment, located outside of the code fragment being reviewed, to figure out the significance of a variable which is being used when a descriptive variable name can document its own purpose and significance in-place.

There are other design issues related to this, described quite well in the book I mentioned above. The shortest summary is that named variables help a programmer manage the complexity of the project, while magic numbers do not. A magic number is improved by a descriptive comment, but is still inferior to a named variable. But my main point is that your preferred approach on this offers no advantages over a named variable, not even saving time, while being less clear, less concise, and less expandable.

I would suggest that you think a bit more broadly about both approaches when comparing them. Just because you aren't using named variables in these cases doesn't mean that they are useless, and aside from satisfying your pre-existing preference your style isn't even providing the one benefit you attributed to it. I would be interested to hear any other arguments you have, but at the moment I am entirely unpersuaded.

EDIT: Added quote to make the response clearer.

Edited by Khaiy, 23 July 2013 - 06:26 PM.

-------R.I.P.-------

Selective Quote

~Too Late - Too Soon~

### #20EarthBanana  GDNet+

Posted 23 July 2013 - 10:16 PM

In the case I was talking about it was a simple mistake - I was just in a hurry testing my grid system... a comment or a good variable name - both good solutions to the problem.

My tip really was more aimed at when your in a hurry and just throwing numbers around to test stuff - or code around in general - make sure if you were to not see that piece of code for weeks you could easily see why its there.. This situation happens a lot I think and a simple variable or comment could have saved me some time (it turns out I got distracted with something else and didn't look at that code again for a few weeks).

Moral of the story always try to write your code as if someone else is going to read it - it may seem a bit tedious but the time saved is almost always more than the time it takes to write code that way

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.