Tips & tricks

[Sven Schüle]

• Use some sort of version control system! What VCS you use is largely a matter of taste (except I would recommend a modern distributed VCS like Darcs, git or Mercury rather than an old-fashioned centralized VCS like Subversion or CVS), but you should definitely use one.

I fully agree.

• Never try to do something difficult! C and C++ are very low-level languages, and using them to do something difficult is asking for trouble. When you are faced with some difficult problem, leave your computer, sit down with pencil and paper in your favorite park or café, and work out how to decompose the difficult problem into tiny and trivial sub-problems. Afterwards, go home and code your solutions to these trivial sub-problems. This approach gives you much clearer and less buggy code than if you just try to attack the difficult problems head-on, and saves you a lot of time in the long run. An additional advantage is that you get a chance to be away from your computer for a while.

I fully agree, although sometimes I find myself breaking that rule

• A related point: Don't debug! If your code doesn't work, and it isn't easy to see precisely what is wrong, it's a sure sign that it is too complex. Discard the old code and replace it with something simpler and clearer.

Here I can agree partially only. A powerful runtime debugger (e.g. the one of Visual Studio), used efficiently (depends on the developer's level of experience), may save a huge amount of development time when trying to find very stupid bugs in very simple code. You are right of course when the root cause of problems is code complexity but I'm quite sure there are many of these stupid bugs around in everyone's code which are not found by reading the source again and again, so you must debug somehow in this case.

I also learn quite a lot from finding my own bugs, which would be impossible when throwing away the code which contains an unknown bug.

Sven

[Fermin Serrano]

[*]Use some sort of version control system! What VCS you use is largely a matter of taste (except I would recommend a modern distributed VCS like Darcs, git or Mercury rather than an old-fashioned centralized VCS like Subversion or CVS), but you should definitely use one.

Uhmmm.... It is a good advise, but never find myself using one of this tools, because they look to me too much "complex", or maybe too much funcionality when only need to save versions. I use a directory where I create one new dir per new version, and a txt to track files. Systems like VCS need a cliente side and a server side software. I don't know if they would worth a try.
Is it there any more simple too to do versioning? What are your experiences?

[*]Never try to do something difficult! C and C++ are very low-level languages, and using them to do something difficult is asking for trouble. When you are faced with some difficult problem, leave your computer, sit down with pencil and paper in your favorite park or café, and work out how to decompose the difficult problem into tiny and trivial sub-problems. Afterwards, go home and code your solutions to these trivial sub-problems. This approach gives you much clearer and less buggy code than if you just try to attack the difficult problems head-on, and saves you a lot of time in the long run. An additional advantage is that you get a chance to be away from your computer for a while.

Sometimes when I want to clear my mind, I used to use AlgoDraw, which is a very simple flow char tool. It helps you to organize your ideas.
Also I like to write in a txt file or notebook to-dos, ideas, ....

[*]A related point: Don't debug! If your code doesn't work, and it isn't easy to see precisely what is wrong, it's a sure sign that it is too complex. Discard the old code and replace it with something simpler and clearer.

I don't know if this is a general rule. I sometimes dischard and make new code and other try to fix de problems.

[Tord Romstad]

[*]Use some sort of version control system! What VCS you use is largely a matter of taste (except I would recommend a modern distributed VCS like Darcs, git or Mercury rather than an old-fashioned centralized VCS like Subversion or CVS), but you should definitely use one.

Uhmmm.... It is a good advise, but never find myself using one of this tools, because they look to me too much "complex", or maybe too much funcionality when only need to save versions. I use a directory where I create one new dir per new version, and a txt to track files. Systems like VCS need a cliente side and a server side software. I don't know if they would worth a try.
Is it there any more simple too to do versioning? What are your experiences?

What you write above is a good description of Subversion and CVS. They are solid, powerful and reliable tools, but tend to be too heavy, bureaucratic and complicated to set up and use for single-user projects. That's why I recommended using one of the modern distributed version control systems (which don't distinguish between the client and server side) instead.

My personal preference is for Darcs, which is extremely easy and pleasant to use, and has a nice and very readable online help system. You should be able to learn everything you need to get started within half an hour, and the more advanced features can be learnt later (if you ever need any of them). The Darcs Wiki is probably the best place to go to learn the basics.

Caveat: I'm a Unix user. I know that Darcs exists for Windows, too, but I don't know if it's equally comfortable to use there.

Tord

[Aleks Peshkov]

If you ever installed CygWin/MinGW for Windows, then Subversion + Eclipse IDE (with Subclipse plugin) is not difficult to install and run.

I have to understand only two questions about version systems:
How to create a new clean project?
How to undo changes that were already committed to database?

[Tord Romstad]

I have to understand only two questions about version systems:

For Darcs:

How to create a new clean project?

Code: Select all

darcs init
darcs add *.h *.cpp
darcs record

How to undo changes that were already committed to database?

Code: Select all

darcs unrecord

Darcs will prompt you for each patch that has been committed (starting with the most recent one) whether you want it removed. As an alternative, it is of course possible to simply extract a copy of the repository from any point backwards in time.

Tord

[Aleks Peshkov]

For average GUI user command-line interactiveness is a disadvantage. As far as I understand Darcs currently has no GUI support.

[Aleks Peshkov]

I have to understand only two questions about version systems:
How to create a new clean project?
How to undo changes that were already committed to database?

I meant that I had to read manual for above questions, all the rest was obvious without any guides. Menu item Team->Commit... behaves similar to File->Save As....

[rjgibert]

My "most wanted trick": Is there any way to detect at compile-time whether you are running on a 32-bit or 64-bit CPU?

Probably the relevant question is detecting whether you are running on a 64 bit OS.

[EugeneCarey]

[*]Use some sort of version control system! What VCS you use is largely a matter of taste (except I would recommend a modern distributed VCS like Darcs, git or Mercury rather than an old-fashioned centralized VCS like Subversion or CVS), but you should definitely use one.

Uhmmm.... It is a good advise, but never find myself using one of this tools, because they look to me too much "complex", or maybe too much funcionality when only need to save versions. I use a directory where I create one new dir per new version, and a txt to track files. Systems like VCS need a cliente side and a server side software. I don't know if they would worth a try.
Is it there any more simple too to do versioning? What are your experiences?

If you are a Windoze user, there are several GUI's for CVS & SVN. (And probably others.) I think there is even the "Tortoise" line (TortoiseSVN & TortoiseCVS) that integrates right into Windows Explorer.

They can be very useful for experimenting with various programming ideas and lets you add extensive commenting for each version and go back to an earlier version if you change your mind, etc. It really makes it convenient to experiment with reorganizations and other radical changes.

For a large project, they are nearly a necessity. For a smaller project, they can be extremely useful.

Now, having said that, they can also be a major problem. *ALL* of these versioning programs (CVS, SVN, RCCS, Dars, whatever) are flawed in that you have to use the program to gain access to your archives.

It sounds obvious, but what are you going to do in 15 years when you want to go back through your old chess programs and look at what you wrote, the ideas you had, and so on.

I've certainly got programs (chess and others) that I wrote 20 years ago that I've looked at since then and like still being able to play with now.

So I would actually recommend a hybrid aproach. Use the versioning program for day to day usage, and then every week or every major change, zip it all up with some comments and store that.

I would also suggest using zip rather than some of the newer formats (7Z or bz2) that offer better compression. Zip has become a defacto standard and it's likely that in 20 years, you'll still be able to find a tool to unzip the stuff.

[EugeneCarey]

4) When commeting, I do it as follow:

Code: Select all

   /*
      myfunc()
      if (x=y) {
         ...
      }
      ...
      mufun2();  /**/

So when I want to uncomment, I only remove the first line. It is
a faster way than usual, where you need to remove the */ also.

FS

I think nested comments like that are generally considered to be poor practice.

Although the C preprocessor is supposed to ignore everything until the closing */ I have heard of people running into trouble occasionally. Not every compiler always behaves correctly.

And the more complicated the code is that you are trying to comment out, the greater the chance that you might forget later.

I think most people prefer the classic #if 0 approach. Although that does have the disadvantage of not letting the editor syntax color the block so you can immediately see it's inactive code.

[Ilari Pihlajisto]

I think most people prefer the classic #if 0 approach. Although that does have the disadvantage of not letting the editor syntax color the block so you can immediately see it's inactive code.

Some text editors figure it out just fine. Gedit is one that does.

[Zach Wegner]

I think most people prefer the classic #if 0 approach. Although that does have the disadvantage of not letting the editor syntax color the block so you can immediately see it's inactive code.

Some text editors figure it out just fine. Gedit is one that does.

Don't forget Vim!