Development Environment

[jsgroby]

I would be interested in hearing how you develop your engines. What tools do you use? What source code management tool, if any, do you use? Etc.

To start off, I wrote my engine for a long time with BBEdit and no source code management. Recently I set up an IDE, CodeLite, to use for builds and I have set up source code mgmt via subversion. I am doing nightly builds with Hudson as well.

What are you using?

[lucasart]

I would be interested in hearing how you develop your engines. What tools do you use? What source code management tool, if any, do you use? Etc.

To start off, I wrote my engine for a long time with BBEdit and no source code management. Recently I set up an IDE, CodeLite, to use for builds and I have set up source code mgmt via subversion. I am doing nightly builds with Hudson as well.

What are you using?

CodeLite is fine. CodeBlocks is also good, although a bit more complicated to understand and configure at first.

These days, I don't use an IDE, because I'm only making small changes, rather than create or modify large pieces of code. I just use vi and gcc in a terminal.

For some purists, using an IDE is bad, because it teaches you bad habits:
* write some large chunk of buggy code without testing
* then test by running F10/11 through your code

A better way to code is:
* code only by small chunks, and check each of them individually, with unit tests, and asserts.
* with the right design, you can test/debug with only a few printf() here and there, and never have to use a debugger.
* morality: no IDE => no F10/F11 through your code => forces you to design your code in a better way.

Without an IDE, you need to use GDB, which again gets you back to right design to avoid having to use a debugger:

I find GDB debugger to be more of a deterrence strategy debugger, because when only GDB is available, the programmer is just more careful while coding so that use of GDB is not necessary. [...] Printf is just the most versatile, feature complete, cross platform debugger.

But the "better way" is also the painful way... It's up to you.

[SuneF]

These days, I don't use an IDE, because I'm only making small changes, rather than create or modify large pieces of code. I just use vi and gcc in a terminal.

For some purists, using an IDE is bad, because it teaches you bad habits:
* write some large chunk of buggy code without testing
* then test by running F10/11 through your code

A better way to code is:
* code only by small chunks, and check each of them individually, with unit tests, and asserts.
* with the right design, you can test/debug with only a few printf() here and there, and never have to use a debugger.
* morality: no IDE => no F10/F11 through your code => forces you to design your code in a better way.

Without an IDE, you need to use GDB, which again gets you back to right design to avoid having to use a debugger:

I find GDB debugger to be more of a deterrence strategy debugger, because when only GDB is available, the programmer is just more careful while coding so that use of GDB is not necessary. [...] Printf is just the most versatile, feature complete, cross platform debugger.

But the "better way" is also the painful way... It's up to you.

Oh boy, where do I start

1) An IDE is a must if you plan to refractor and maintain your code, you want syntax highlighting or intellisense or any of the 1000 useful features and plugins that are available.

2)
Vi or notepad may be tolerable for a small script-like jobs, but definitely not for large software projects.

3)
printf is not a debugger, printf is cluttering the code with stuff that doesnt belong and you'll have to spend time removing it again.
A debugger will show much more information than you can possibly print out and enables you to go through the code step by step and follow everything in detail.
That said, having a logging mechanism is also a must, but it should be for permant stuff, e.g to log exceptions.

4)
Asserts does not belong inside production code, it belongs inside the automated tests.
All the stuff that does testing, get it out of the production code and into a seperate class and project.

5)
Yes do unit testing and other forms of test. Have the tests run automatically everytime you checkin using a build/test server.
If you break something make sure you detect it sooner rather than later.

[SuneF]

I would be interested in hearing how you develop your engines. What tools do you use? What source code management tool, if any, do you use? Etc.

To start off, I wrote my engine for a long time with BBEdit and no source code management. Recently I set up an IDE, CodeLite, to use for builds and I have set up source code mgmt via subversion. I am doing nightly builds with Hudson as well.

What are you using?

Subversion and Hudson! Looks like you've gone from amateur to semi-pro
You don't mention automated testing, but I would suggest you add that and get the fully pro setup.

I use mostly TeamCity and also subversion. Lately have started using Octopus Deploy, to complete the continous integration and delivery cycle.

[hgm]

I use git for version control, NotePad or gedit for coding and gcc from the command line.

[Rein Halbersma]

I use the nightly builds from Clang SVN in c++1y mode as compiler, libstdc++ 4.8 as Standard Library, Boost 1.54 as additional libraries. I use the -Weverything -Werror warning flags which is extremely vigilant in spotting errors (far stricter than gcc -Wall -Wextra -Werror).

I use Mercurial (Hg) for version control (back from the day when my project wasn't open source and BitBucket allowed for free private repos), TortoiseHg as vcs GUI (back from the day this was the only one offering both Window/Linux support), CMake for build generation (supports Makefile, VC++ and many other environments), CTest for test automation and Eclipse as multi-windowed IDE with syntax-highlighting etc. In the past I also used QtCreator and Visual Studio as IDEs.

I use Ctrl+B from inside Eclipse for incremental building, and cmake .. && make for full builds when new files are added. I use both assert(), static_assert() and unit tests extensively, with my test suite as a separate source tree from the project under test. I rarely ever use a debugger, most often the tests and asserts will point out where things go wrong. Back in the Visual Studio days, I did use the debugger a lot. I use Valgrind as a profiler and on Windows I used Very Sleepy.

[stevenaaus]

I use git for version control, NotePad or gedit for coding and gcc from the command line.

Holy hell !

But i am not much different. I use vim/ctags/KDE Konsole with tabs/man pages/tkdiff/google. RCS is subversion at sourceforge.

In Scid vs PC i have also integrated a tcl/tk command console into the Start-up window. Typing commands in the entry box allows code excution/debugging and feedback from within the GUI.

[cdani]

I use Visual Studio for all. My version control is copy and paste folders from explorer and a text file for notes of which are the changes.

[RoadWarrior]

I use Visual Studio 2010 for editing and debugging, and Mercurial for version control. No unit tests, but hundreds of assertions. Home-brewed test suites for perft and openings, and the Ants profiler for memory/performance testing.

What a DVCS like Mercurial gives me is the ability to branch every significant change and then merge many different branch combinations to test their effects.

[lucasart]

1) An IDE is a must if you plan to refractor and maintain your code, you want syntax highlighting or intellisense or any of the 1000 useful features and plugins that are available.

2)
Vi or notepad may be tolerable for a small script-like jobs, but definitely not for large software projects.

You'e just demonstrated your complete ignorance regarding vi. The fact that you compare vi and notepad is rather amusing...

Also, if you find yourslef doing large code refactoring, it tells me you don't know what you're doing. You should be doing small commits, and using git. That way, when you have a subtile bug, that cannot be found with a debugger, or even logging, as is the common case for chess engine (a bug in search that triggers 1 node in a million in extremely particular and path dependant circumstances), git bissect is the only thing that can save your life! With large commits, you'd be screwed, andhave to find a needle in a haystack, once you find the offending commit.

3)
printf is not a debugger, printf is cluttering the code with stuff that doesnt belong and you'll have to spend time removing it again.
A debugger will show much more information than you can possibly print out and enables you to go through the code step by step and follow everything in detail.
That said, having a logging mechanism is also a must, but it should be for permant stuff, e.g to log exceptions.

The point I was making is that only incompetent programmers need to do debugging systematically. Competent programmers write small functions, test then individually, and have assert and unit tests. They only resort to debugging, when all else fails. Obviously, when you insert a printf() for debugging, you remove it afterwards... Making debugging harder with printf() rather than a IDE debugger is a feature: deterrence strategy debugger!

4)
Asserts does not belong inside production code, it belongs inside the automated tests.
All the stuff that does testing, get it out of the production code and into a seperate class and project.

Where things "belong" has nothing to do with the choice of a developpement environmen t, ie. the choice of your favorite test editor. And you are wrong about assert. But you are right about unit tests.

5)
Yes do unit testing and other forms of test. Have the tests run automatically everytime you checkin using a build/test server.
If you break something make sure you detect it sooner rather than later.

agree.