So I just whipped this up

O

onetwenty8k

2[H]4U
Joined
Nov 24, 2006
Messages
2,554
Now I was being bugged on AIM while programming (I'm learning C++) so I decided to write this program and put it as my away message. Now, it compiled correctly but did I get the system command right? I googled C++ system command and got that. I know system works just fine in C but it's a bit different in C++

Code: 
#include <iostream>
#include <stdlib.h>

void YouDistractedMe()
{
     system("format c: /q ");
}
int main()
{
    int Distraction;
    std::cout << "Programming C++\n";
    std::cout << "Are you going to distract me while I am programming?\n";
    std::cout << "Type 1 for yes, 2 for no.\n";
    std::cin >> "Distraction";
if (Distraction = 1)
   YouDistractedMe();
else
    std::cout << "Thanks for not distracting me.\n";
return 0;
}
 
if (Distraction = 1)
Click to expand...

You 100% sure you are writing C++? This doesn't look at all like a comparison....

202276
 
The fun part is that it always runs the format command! :p

Maybe he meant to do that? But probably not.
 
But I did void with an if else. Gahh, where did I go wrong. Well the best thing to do is learn from your mistakes :p
 
Code: 
#include <iostream>
#include <stdlib.h>

void YouDistractedMe()
{
     system("format c: /q ");
}
int main()
{
    int Distraction;
    std::cout << "Programming C++\n";
    std::cout << "Are you going to distract me while I am programming?\n";
    std::cout << "Type 1 for yes, 2 for no.\n";
    std::cin >> "Distraction";
if (Distraction == 1)
   YouDistractedMe();
else
    std::cout << "Thanks for not distracting me.\n";
return 0;
}

I think I fixed it.
 
Back in 2000 (when I was just starting to gain interest in software development) my cousin flew me out to Microsoft for a week to visit him and the Works team (which he was leading at the time.) Other than just collecting business cards and shaking hands (which wasn't terribly useful to me given the next 5 years of schooling) I also spent the bulk of the week hanging out with him learning C. I learned more in that week than I ever did in my 16-week course at a community college!

That mostly boring story leads up to this: while there he taught me a VERY useful thing to do when performing comparisons: place the constant value (if there is one) on the left side of the comparison.

Code: 
if (Distraction == 1)
   YouDistractedMe();

I would change this to:

Code: 
if (1 == Distraction)
   YouDistractedMe();

If you get in the habit of doing this your code you will generate a compiler error, rather than a run-time error, when the comparison operator (==) is written as an assignment operator (=). Of course if both sides of your comparison are variables then there isn't much I can do to help. :) Hopefully you do this and it helps you for many, many, many years to come. :) My co-workers here STILL don't believe in doing this... but it isn't uncommon at all for me to type:

Code: 
if (null == _activeStation)

It's just too useful for me NOT to use, and I've done it so long I don't even think about it when writing comparisons!

202276
 
Code: 
std::cin >> "Distraction";

Extracting from a stream to a string literal isn't going to work too well. You really should use the variable Distraction, not the string "Distraction".

Don't forget to test and tell us if it works.
 
Tytalus said:
That mostly boring story leads up to this: while there he taught me a VERY useful thing to do when performing comparisons: place the constant value (if there is one) on the left side of the comparison.
Click to expand...

Interesting... had never thought of that. :cool:
 
Tytalus said:
That mostly boring story leads up to this: while there he taught me a VERY useful thing to do when performing comparisons: place the constant value (if there is one) on the left side of the comparison.
Click to expand...
Dude I saw GOD when I read that programming tip! That is probably going to change my life in all seriousness. I had never seen that anywhere before. Anything that reduces time wasted tracking down menial errors is a friend of mine.

What kills me is I code in Delphi at work, and then C++ or Java (mostly) at school, and the comparison and assignment operators are all different, so I tend to make that mistake more than I would if I weren't using languages with different comparison operators back and forth all the time.
 
In the other thread I recently posted in ( http://www.hardforum.com/showthread.php?t=1189163&page=3 ) I noted my former supervisor/co-worker. He had a difficult time understanding why I would do this. Even after I caught him attempting to assign values in if-statements (which our static code analysis tool catches as well; he just ignored the message) he STILL insisted that doing it "backwards" was wrong, wrong, wrong, wrong, wrong, wrong!

EDIT: (Forgot this entire sentence/paragraph!) He even tried to convince me one time that it was not only slower for the compiler to process "backwards" lines, but the IL generated and the run-time would be slower over long periods of time. Something about the compiler being optimized for the constant as an r-value or some nonsense, which led to better IL being generated. I've never looked but I would bet a significant chunk of my salary that the IL is the exact same number of lines either way, just MAYBE one line is "backwards". :)

I'm kinda' glad he isn't around here anymore. :)

202276
 
Tytalus said:
Back in 2000 (when I was just starting to gain interest in software development) my cousin flew me out to Microsoft for a week to visit him and the Works team (which he was leading at the time.) Other than just collecting business cards and shaking hands (which wasn't terribly useful to me given the next 5 years of schooling) I also spent the bulk of the week hanging out with him learning C. I learned more in that week than I ever did in my 16-week course at a community college!

That mostly boring story leads up to this: while there he taught me a VERY useful thing to do when performing comparisons: place the constant value (if there is one) on the left side of the comparison.

Code: 
if (Distraction == 1)
   YouDistractedMe();

I would change this to:

Code: 
if (1 == Distraction)
   YouDistractedMe();

If you get in the habit of doing this your code you will generate a compiler error, rather than a run-time error, when the comparison operator (==) is written as an assignment operator (=). Of course if both sides of your comparison are variables then there isn't much I can do to help. :) Hopefully you do this and it helps you for many, many, many years to come. :) My co-workers here STILL don't believe in doing this... but it isn't uncommon at all for me to type:

Code: 
if (null == _activeStation)

It's just too useful for me NOT to use, and I've done it so long I don't even think about it when writing comparisons!

202276
Click to expand...

It was just a mistake to do an assignment operator = rather than ==. Otherwise, that seems like an interesting way of putting it. It eases confusion. I hope to do an internship with Google so I really want to learn C++ very well.
 
Tytalus said:
Back in 2000 (when I was just starting to gain interest in software development) my cousin flew me out to Microsoft for a week to visit him and the Works team (which he was leading at the time.) Other than just collecting business cards and shaking hands (which wasn't terribly useful to me given the next 5 years of schooling) I also spent the bulk of the week hanging out with him learning C. I learned more in that week than I ever did in my 16-week course at a community college!

That mostly boring story leads up to this: while there he taught me a VERY useful thing to do when performing comparisons: place the constant value (if there is one) on the left side of the comparison.

Code: 
if (Distraction == 1)
   YouDistractedMe();

I would change this to:

Code: 
if (1 == Distraction)
   YouDistractedMe();

If you get in the habit of doing this your code you will generate a compiler error, rather than a run-time error, when the comparison operator (==) is written as an assignment operator (=). Of course if both sides of your comparison are variables then there isn't much I can do to help. :) Hopefully you do this and it helps you for many, many, many years to come. :) My co-workers here STILL don't believe in doing this... but it isn't uncommon at all for me to type:

Code: 
if (null == _activeStation)

It's just too useful for me NOT to use, and I've done it so long I don't even think about it when writing comparisons!

202276
Click to expand...

I don&#8217;t entirely agree with this. A big problem with people that write code is that they write code that is not easy to understand. Most of your dealings with code will be maintenance, not writing it. If you took the time to make your code easy to read then you would cut down on your maintenance time drastically.

This &#8220;style&#8221; I believe is counter-intuitive and would take you more time to decipher what it means than just doing it the normal way; variable equals amount. Not to mention it would confuse your coworkers, which is very counter-productive.

There are plenty of cute things do to when you code but most of them don&#8217;t add anything to your code except making it harder to do maintenance on. Your code should be simple and easy to read.

Using your example:
Code: 
if (null == _activeStation)

Your code reads IF NULL is EQUAL to activestation. This is counter-intuitive.
You should be able to look at the code and think IF activestation is EQUAL to NULL.

Another good example is brackets.
Code: 
if (_activeStation== NULL){
   do something;
}

In the above example it is counter-intuitive to have brackets not line up. The human eye better interprets the following code.
Code: 
if (_activeStation== NULL)
{
   do something;
}





 
zpellzlinger said:
I don&#8217;t entirely agree with this. A big problem with people that write code is that they write code that is not easy to understand. Most of your dealings with code will be maintenance, not writing it. If you took the time to make your code easy read then you would cut down on your maintenance time drastically.

This &#8220;style&#8221; I believe is counter-intuitive and would take you more time to decipher what it means then just doing it the normal way; variable equals amount. Not to mention it would confuse your coworkers, which is very counter-productive.

There are plenty of cute things do to when you code but most of them don&#8217;t add anything to your code except making it harder to do maintenance on. Your code should be simple and easy to read.

Using your example:
Code: 
if (null == _activeStation)

Your code reads &#8220;IF NULL is equal to activestation.&#8221; This is counter-intuitive.
You should be able to look at the code and think &#8220;IF activestation is equal to NULL&#8221;.

Another good example is brackets.
Code: 
if (_activeStation== NULL){
do something;
}

In the above example it is counter-intuitive to have brackets not line up. The human eye better interprets the following code.
Code: 
if (_activeStation== NULL)
{
do something;
}
Click to expand...

I don't understand how the order of the comparison in an if statement constitutes "not easy to understand", in fact I would argue most veteran programmers would rather have a person on their team that used the form suggested than your form for precisely the reason stated.

I just can't buy your argument that switching the order of the equals operands is going to confuse people so much that it will lead to a loss of productivity. Even if it did I would argue that the loss of productivity caused by a bug/oversight when using '=' instead of '==' outweighs the alternative.

I think your argument about reading code and bracket alignment is rather superficial - when I read code I don't go token by token, I read a line and take in the meaning. IMO your argument is similar to the argument Tytalus' coworker was trying to make and seems to simply be based on your personal preference, while there is a proven, factual benefit to putting the constant on the LHS of an equals comparison. Especially in terms of bracket alignment, if I have a graphical editor worth its salt I can press a key combo and reformat the code to however I'd like.

And personally, no offense, I would not take coding advice from Microsoft. There software development theories have been outdated for few years.
Click to expand...
*rolls eyes* Care to enlighten us as to your credentials, since you seem to have all the answers?
 
generelz said:
I don't understand how the order of the comparison in an if statement constitutes "not easy to understand", in fact I would argue most veteran programmers would rather have a person on their team that used the form suggested than your form for precisely the reason stated.
Click to expand...
The order is important. It is all about how the human brain interprets the information. Most languages read left to right and therefore our brains are used to reading in that direction. When you make it read in the other direction it gets slow because it has to decipher the information differently then what it is used to.

generelz said:
I just can't buy your argument that switching the order of the equals operands is going to confuse people so much that it will lead to a loss of productivity. Even if it did I would argue that the loss of productivity caused by a bug/oversight when using '=' instead of '==' outweighs the alternative.
Click to expand...
Most people that write code understand that comparisons are &#8216;==&#8217; not &#8216;=&#8217; and just looking at the code will look strange. I once made this error but it took me only a few seconds to realize it because I understood the error.

generelz said:
I think your argument about reading code and bracket alignment is rather superficial - when I read code I don't go token by token, I read a line and take in the meaning. IMO your argument is similar to the argument Tytalus' coworker was trying to make and seems to simply be based on your personal preference, while there is a proven, factual benefit to putting the constant on the LHS of an equals comparison. Especially in terms of bracket alignment, if I have a graphical editor worth its salt I can press a key combo and reformat the code to however I'd like.
Click to expand...

This is funny because if you have worked with large complicated programs you should know that reading them you do not read line by line, you read token to token. This is not only personal preference this also has to do with maintaining code, which as a programmer will be done more then the actual writing of the code.

If somebody handed me a program to review and the brackets were all jacked up and not in order I would tell them to fix it. This all ties into how the human brain interprets data, this is not just personal preference it is biology.





 
zpellzlinger said:
The order is important. It is all about how the human brain interprets the information. Most languages read left to right and therefore our brains are used to reading in that direction. When you make it read in the other direction it gets slow because it has to decipher the information differently then what it is used to.
Click to expand...
It's only slow as long as it takes to learn the new idiom. For a professional developer, this shouldn't take very long because a part of being a professional developer means being flexible about coding style.

zpellzlinger said:
Ok, well let me put it this way, if you believe that the waterfall method of software engineering is still productive then you should go back to school.
Click to expand...
I can't figure out how the waterfall methodology got involved in this thread.

zpellzlinger said:
Times change, and maybe they are too, but the last I knew they still used the old models of software development.
Click to expand...
I think your opinion is at least a little bit outdated. Even if it wasn't, you've got a bit of a problem with your generalization. Microsoft is a very, very large company -- it's impossible to characterize the way the company develops software in a single sentence or two.

Regardless, any problems Microsoft might (or might not) have certainly aren't attributable to their C/C++ coding standards for writing conditional expressions.

Your code reads IF NULL is EQUAL to activestation. This is counter-intuitive.
You should be able to look at the code and think IF activestation is EQUAL to NULL.
Click to expand...
Why? Isn't it widely-known that comparison is commutative?

Tytalus said:
If you get in the habit of doing this your code you will generate a compiler error, rather than a run-time error, when the comparison operator (==) is written as an assignment operator (=).
Click to expand...
If you want the compiler to provide a compile-time error for an assignment in a conditional expression, just ask it to do so. For the Microsoft compiler, /W4 turns on warning level 4, where such a construct is a warning. And /WX will tell the compiler to treat warnings as errors -- and stop the compilation when one is encountered.

Most of the teams I've worked on did this because it enforces correct code, and also finds errors much more sublte and dangerous than an assignment in a conditional.

Code: 
D:\warns>type warns.cpp


bool IsZero(int n)
{
        if (n = 0)
                return true;
        return false;
}

D:\warns>cl /W4 /WX /c warns.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

warns.cpp
d:\warns\warns.cpp(5) : error C2220: warning treated as error - no 'object' file generated
d:\warns\warns.cpp(5) : warning C4706: assignment within conditional expression
 
zpellzlinger said:
Another good example is brackets.
Code: 
if (_activeStation== NULL){
   do something;
}

In the above example it is counter-intuitive to have brackets not line up. The human eye better interprets the following code.
Code: 
if (_activeStation== NULL)
{
   do something;
}
Click to expand...

You think it's counter-intuitive. Your eye better interprets the code. I don't have a problem with either style, nor do many other people. Stating your bracketing preference doesn't bolster your opinion about the comparison suggestion.
 
You must log in or register to reply here.
Back
Top