Visual Layout

#include <iostream>
using namespace std
;int main(){int x,y
=1;cin>>x;while(x>0
){y=2*y;x--;}cout<<
y<<endl;return 0;}

#include <iostream>
using namespace std;

int main()
{
  int x, y = 1;
  cin >> x;

  while(x > 0)
  {
    y = 2*y;
    x--;
  }

  cout << y <<endl;
  return 0;
}

Curly Braces, i.e. { }'s

while (x < 3)
{
  cout << x << ",";
  x++;
}
cout << endl;

while (x < 3) {
  cout << x << ",";
  x++;
}
cout << endl;

while (x < 3)
{ cout << x << ",";
  x++; } 
cout << endl;

while (x < 3)
{ cout << x << ",";
  x++;
} cout << endl;

Comments

/***************************************************
Fahrenheit to Celsius Conversion
***************************************************/
#include <iostream>
using namespace std;

int main()
{
  // Read temperature in Fahrenheit
  double Tf;
  cout << "Enter temperature in Fahrenheit: ";
  cin >> Tf;

  // Compute temperature in Celsius
  double Tc;
  Tc = (Tf - 32)*(5/9.0); // .0 forces division as double

  // Write temperature in Celsius
  cout << "That is " << Tc << " degrees Celsius." 
       << endl;

  return 0;
}

Naming

• Variables should have meaningful names.
  For example, consider a program that uses a variable to track the yards per carry of a football game. Such a variable should be called yardsPerCarry vice ypc for program readability. This must be balanced against using names which are too long, which can obscure the code. (Fifteen or so characters approaches the "too long" limit.)

  It should be mentioned that this is most important for variables that have large scope — i.e. they are visible and need to be used either from different files or from widely separated lines in the same file. The code example above seems to violate this rule, but variables Tf and Tc only a appear, and are only in scope, within less than a dozen lines of code, and in the context of those few lines they are descriptive enough. Also, because this is an example embedded in a document, compactness of the code is very important.

• Single letter variables or constants should not be used.
  An exception to this rule is when it is common practice to identify something with a single letter. An example of this is the coordinate system (x, y, and z). A second exception occurs in the use of loop counter variables where it is common practice to use variables like i and j as counters in for loops.

• Function names and variable names should begin with a lower case letter.
  An identifier consisting of multiple names SHALL have each name distinguished by making the first letter of each name part (after the first) upper case (e.g. yardsPerCarry) or by using underscores (yards_per_carry). The former method is strongly encouraged.

• Constants should be named in all upper case letters.
  Example:

  const int PI = 3.14;

  It's generally good to avoid lower case letter 'L', or the letter 'O' in names unless they are part of normal words. This is to avoid confusion with the numbers 1 and 0. For example, is "cell" c- e - 1- ONE or c- e- 1-1?

• Avoid names that differ only in case, look similar, or differ only slightly.
  For example, InputData, InData and DataInput will certainly be confusing if used in the same program.

• Names of functions should reflect what they do (printArray), or what they return (getAge).

• Boolean variable names should sound like Yes/No things — "isEmpty" and "isFinished" are possible examples.

Miscellaneous but Important Stuff

• No line of code should wrap beyond the right margin. If a line of code becomes too long, break it up into pieces. Remember the compiler largely ignores extra whitespace in your programs (but be careful with strings).
• Always use the most appropriate operator or construct for the work you want it to do. Good design and clarity take precedence over optimization. Do not declare or use more variables than are necessary.
• Numerical constants ("magic numbers") must not be coded directly. The only allowable exceptions are for 0, 1 or -1, and those which are not likely to change; for example code determining if a number is even can use the number 2 since it is not likely to change. Numerical constants must have a comment explaining the value if it is not evident from the name.

Practical tips for tackling programming problems

• The more independent a programmer is, the better. Of course, you need to look at lecture notes, sample programs, and other materials to write your program. However, do this before writing the code, but try to avoid looking at them if possible while writing your code. In particular, if you are really new to programming, try to write your code from scratch without doing any copy-and-paste, at least for the first three weeks. I know it's impossible to do so; try with your discretion.

  There are some benefits to this approach:

  • You will become more conscious which concepts (or less important details) you miss. This way, you can identify your misunderstandings and fix them with more ease.
  • You will write a code faster. Access to something in your brain is much faster than in any other storage. Memory hierarchy matters.
  • Your brain seems to do creative synthesis. You may gain more fundamental perspectives on programming if you put more in your brain. However, things outside your brain always stay the same to you.

• The devil is in the details. Don't forget that is it you as a programmer who are responsible for all the bits and pieces of your program. Things may seem simple at a first look, but usually they will take more time and effort to complete than expected.

  As one more example, the online notes sometimes explain technical details. In this case, reading one paragraph may take even 5 minutes or more to work out all the details in your brain. Don't skip through the details. The devil is in the details.

• Step back, and think again. When you finish a task, take a brief moment and step back. Check if you get both the big picture logic and the small details to implement the logic. See if there are some inconsistencies and fix them if any.

• How valuable is a car that doesn't run? It's useless, and I won't buy the car. Likewise, however many lines your source code may have, if it doesn't work, it's useless, and I won't buy your program. Try to make a good, working product. If your code doesn't work, you are missing something; what is it?

Tips for managing your time

• Reading one day's lecture notes.
• Finishing one assignment of homework.
• Finishing a lab.