TR Forums

whm1974 wrote:

Well at least I'm learning to avoid writing bad code.

whm1974 wrote:

just brew it! wrote:

In the real world, the process we just went through with that simple program would've been called a "code review". Code reviews are part of the process in well-run development groups. In a nutshell, you get one or more developers other than the original author of the code to analyze it, looking for potential bugs.

I can imagine that it is nearly impossible for one person to write code for highly complex and large program without being really buggy.

Redocbew wrote:

whm1974 wrote:

Well at least I'm learning to avoid writing bad code.

The phrase you might hear about that is "if the program works perfect with perfect input, then you're only half done".

Here's a real world example. At my last job I had a bug to deal with which seemed to be causing confusion between payment processors. At the time there was both paypal and a credit card available for payment methods, and it looked like a few people had managed to find a way to use both paypal and a credit card to place an order. It wasn't split payments where a portion was being placed on each. It was just a weird, bad order that the system choked on, and then caused the customer service folks headaches having to clean it up. It was doubly weird because the paypal entry form wasn't even part of the application its self. That was external, with service calls going back and forth between the two(hint: never really been a fan of paypal since then...). It turned out to be confined to cases where a credit card payment was declined for some reason and the user returned back to the payment page. The problem was that if they then tried to pay through paypal the CC fields were still populated with whatever garbage had been there previously. We cleared the other method any time they switched from one method to the other, and the bug was dead.

whm1974 wrote:

How long did that take to discover the solution? Did it turned out to be so simple that you guys were smacking your heads for taking so long to figure out? I have found that the simplest solutions tend to be the hardest to find.

whm1974 wrote:

just brew it! wrote:

In the real world, the process we just went through with that simple program would've been called a "code review". Code reviews are part of the process in well-run development groups. In a nutshell, you get one or more developers other than the original author of the code to analyze it, looking for potential bugs.

I can imagine that it is nearly impossible for one person to write code for highly complex and large program without being really buggy.

Pancake wrote:

I can imagine that it is nearly impossible for one person to write code for highly complex and large program without being really buggy.

It's the opposite, actually. With good software design and development practices it's entirely possible for one person to develop a highly complex and large program. One great programmer is often better than 10 average to good programmers. It's very difficult getting a team of people to communicate clearly especially if they're not all super-good highly disciplined devs with the confidence to communicate their what they are doing clearly instead of trying to make stuff just work and hide horrors from others who are also too beaten down from working with and managed by idiots.

just brew it! wrote:

Pancake wrote:

I can imagine that it is nearly impossible for one person to write code for highly complex and large program without being really buggy.

It's the opposite, actually. With good software design and development practices it's entirely possible for one person to develop a highly complex and large program. One great programmer is often better than 10 average to good programmers. It's very difficult getting a team of people to communicate clearly especially if they're not all super-good highly disciplined devs with the confidence to communicate their what they are doing clearly instead of trying to make stuff just work and hide horrors from others who are also too beaten down from working with and managed by idiots.

Yeah, quite true. I suppose whm's statement should be reworded "...it can be nearly impossible...", to reflect the fact that a well organized, highly competent developer can accomplish a lot. There will always be bugs, of course... but if things are properly planned and the architecture is well thought out, there should be no major design flaws.

Look at Linus Torvalds, for example. He singlehandedly created the Linux kernel; there are a lot more people working on it now, of course, but at the start it was a solo effort. He also wrote the core of the git version control system in less than a week, in a fit of pique over the fact that BitKeeper was no longer free to use and none of the other extant free version control systems met his needs.

I have worked on small teams which have accomplished amazing things, because everyone was very good at what they did and was willing to wear a lot of different hats. I've also worked on large teams that produced absolute garbage because they were poorly organized, with some people who didn't know WTF they were doing. If you don't have code reviews, one clueless developer can drag an entire project down -- every hour spent by the bad dev collectively results in more than one man-hour spent by the rest of the team dealing with the resulting bugs (i.e. negative productivity).

@whm1974 - Check out a book called The Mythical Man-Month sometime. All developers and (especially) managers of software projects should read it. The central tenet is "adding manpower to a late software project makes it later".

Buub wrote:

I haven't ready through the entire thread to see if this is recommended. Consider it a second opinion if it has.

First, subscribe to OReilly Safari online, where you can read any development book "free" after paying the monthly subscription: https://www.safaribooksonline.com/

Then go start digging into some good, classic C and/or C++ development books. Since I don't do C, and am purely a C++ programmer, I don't any pure C books to recommend.

For learning C++, you can't really get any better than these two:
http://www.stroustrup.com/programming.html
http://www.stroustrup.com/4th.html

Both are available with the Safari subscription, above.

just brew it! wrote:

I think Stroustrup can be a little intimidating to beginners. At least the books of his that I've read seemed that way. Good references though.

#include <stdio.h>

Main()
{
        printf("Hello, World!\n");
}
  

gcc myhello.c
myhello.c:3:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
main()
^~~~

Redocbew wrote:

That's the compiler complaining about the lack of a return statement at the end of the function. Since it's defined as an integer function, the compiler is expecting a return value of an integer. Convention is that in the absence of any errors, main will return 0. I'm surprised it's also not complaining about the function just being declared as "main" instead of "int main", but I guess in the absence of any declared type the compiler must be assuming that int is the intended type.

DancinJack wrote:

You haven't applied a data type or return value for your main function. You need "int" in front of Main, and a return statement before the closing bracket, such as "return 0;"

Redocbew wrote:

Yeah, because that message is a warning, not an error. The difference between the two is murky in some languages, but generally speaking warnings are the compilers way of saying "hey, are you sure you meant to do this?" while errors are "something's definitely broken".

whm1974 wrote:

DancinJack wrote:

You haven't applied a data type or return value for your main function. You need "int" in front of Main, and a return statement before the closing bracket, such as "return 0;"

But it still compiles and runs.

just brew it! wrote:

whm1974 wrote:

DancinJack wrote:

You haven't applied a data type or return value for your main function. You need "int" in front of Main, and a return statement before the closing bracket, such as "return 0;"

But it still compiles and runs.

The compiler is telling you that what you did is bad form and/or may result in unexpected behavior depending on context. That's what compiler warnings are for. "I think I understand what you're trying to do, and I'm going to compile this anyway, but you're doing it wrong", pretty much.

In a lot of cases where warnings are issued (like this one), it would've been considered perfectly normal back in the original (pre-ANSI) C days, and likely would not have resulted in a warning from compilers of the day.

just brew it! wrote:

Many commercial development organizations insist that all code compile warning-free in their coding standards. Some also mandate that the -Wall compiler switch be used; this causes the compiler to be extremely pedantic about warnings. I happen to agree with both of these practices. With few (if any) exceptions, if you can't code it in a way that doesn't result in warnings, "you're doing it wrong".

just brew it! wrote:

Many commercial development organizations insist that all code compile warning-free in their coding standards. Some also mandate that the -Wall compiler switch be used; this causes the compiler to be extremely pedantic about warnings. I happen to agree with both of these practices. With few (if any) exceptions, if you can't code it in a way that doesn't result in warnings, "you're doing it wrong".

Redocbew wrote:

just brew it! wrote:

Many commercial development organizations insist that all code compile warning-free in their coding standards. Some also mandate that the -Wall compiler switch be used; this causes the compiler to be extremely pedantic about warnings. I happen to agree with both of these practices. With few (if any) exceptions, if you can't code it in a way that doesn't result in warnings, "you're doing it wrong".

That was always the way I treated C, even though I've never had a job writing C code. It pays to do the same with PHP and other interpreted languages as well. Otherwise, it just leads to a ton of useless junk in your application logs which you have to sift through in order to find the stuff that's actually important.

whm1974 wrote:

Thanks for the advice, however money is kind of tight right now so I'm trying to limit my cash outflow at the moment.

whm1974 wrote:

just brew it! wrote:

I think Stroustrup can be a little intimidating to beginners. At least the books of his that I've read seemed that way. Good references though.

Yeah I need manual that starts with the basics assumes that the beginner knows nothing about programming or how to compile source code.

Buub wrote:

whm1974 wrote:

Thanks for the advice, however money is kind of tight right now so I'm trying to limit my cash outflow at the moment.

I understand, and urge you to spend as little as necessary. But that's one of the reasons I recommended this option -- it's cheaper than going out and buying books, and they have a relatively inexpensive plan that still allows you to have like ten books on your bookshelf at a time.