Development Environment

[jdart]

Emacs for editing, and command-line tools and scripts for compilation and testing. I used to mainly develop on Windows and I still sometimes fire up Visual C++ if I really need an IDE for debugging, but I'm mostly developing on Linux now (I have four Linux machines). For a long time too as a single developer I didn't have any source control, but now I am on git and find it very helpful, although the learning curve can be steep.

--Jon

[stevenaaus]

Now don't get me started on Git What a friggin' frankenstein.

Linus can do technical things very well, but he does user-friendliness equally as poor. :brick wall:

[Roman Hartmann]

On my desktop with debian installed I use Emacs for editing. In the past I also used VC++ on Windows and XCode on Mac. I don't use any version control beside backing up the source code regularly.

I only use gdb when I have no clue what's going on. Usually I have an idea where the problem is and I put in some printf-statements to find the bug.

Roman

[lucasart]

On my desktop with debian installed I use Emacs for editing. In the past I also used VC++ on Windows and XCode on Mac. I don't use any version control beside backing up the source code regularly.

I only use gdb when I have no clue what's going on. Usually I have an idea where the problem is and I put in some printf-statements to find the bug.

Roman

Using git has really helped me increase my productivity. Honestly DiscoCheck would never be where it is without git: I would have given up long ago! It saved me lots of time of debugging and hunting for regressions. The power of git has no equal, but a single developper working on his own project probably doesn't need most of it. But still the git basics help a lot, even a single developper.

Being able to work by commit, even if you have only one master branch is a huge safety net. Often I found myself screwing up and not remembering what I had modified, and crying little girl for a debugger...

Once you diarize all changes, you can easily revert any screw up. You can also find subtle hidden bugs in O(log(N)) with a dichotomic search throughout the commit history! I remember the day I updated gcc from 4.7 to 4.8 and DiscoCheck started to have incorrect and non deterministic behaviour. This was the kind of subtile bug that no debugging session will ever find! The only thing that saved my life was git bissect (turns out my code was wrong and gcc 4.8 had revealed a bug that 4.7 was coincidently handling the way i intended, undefined behaviour...)

The next useful thing is branches, that way you keep your master clean and do all the experiments you like in branches, that you either merge, or keep in parralel, or delete once you're done with them.

It's a bit of effort to learn git, but it's really worth it.

[SuneF]

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.

Before you insult me maybe you need to fully understand the word refactoring

Refactoring does not necessarily mean big changes. Renaming a variable is also a refactoring, moving a method to another class, or splitting a class in two are other examples of simple refactorings. Refactoring is done constantly on any good and sound agile code.

To do refactoring efficiently you need the assistance of a code-aware IDE, ie an EDI that understands that renaming a function means renaming it everywhere it is used throughout all the files in the project.

Admittedly I am not an expert on VI, it's been 20 years since I used it last However, as I remember, it was a small console editor that knew nothing of software projects as such, that is quite the opposite of a feature rich EDI editor with auto-completion and support of refactoring patterns.

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!

Yes and no, you are mixing things.
Using a debugger does not mean that you write large functions or that you are incompetent and don't write tests, I don't know why you would make that connection.
But I will say that using printf instead of a debugger is certainly a sign that you are not being efficient and comfortable with advanced and modern tools.
This is of course understandable for new programmers, as concentrating on the basics of the code is more important and probably more interesting and fun. However in the long run, spending some time getting familiar with advanced tools and modern software will make you a far more efficient developer.
If you are using VI I can sort of understand why using a debugger is complicated and maybe even harder for you than printf, but if you switch to a modern IDE the debugger will be an integral part and very easy to use.

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.

No. Asserts definitely does not belong inside production code. I can give you several good reason for it.
1) It clutters the code and is just ugly to look at.
2) it only works in debug mode and your program won't be running in debug mode.
3) it throws an exception so it will break your code if it fails.
4) don't focus your tests on the debug mode, use release mode as that is how the software will be delivered and you'll want to test the exact same binary as you deliver.
5) In general don't mix test and production code, that's just poor seperation of concerns.

I completely stopped using debug mode a long time ago, it is pretty useless because the compiler behaves completely different and you therefore cannot trust in the result.

[lucasart]

I completely stopped using debug mode a long time ago, it is pretty useless because the compiler behaves completely different and you therefore cannot trust in the result.

When you rely on undefined behaviour, yes. I think debugging is useful, but should be used as a last resort not to take bad habbits. That's all I'm saying.

And vi, or rather vim, is more powerful than you think (there are vim plugins for lots of stuff). But the choice of text editor, or IDE, is a personal choice, based on habits, etc.

[Ferdy]

I am using tortoiseSVN and git GUI for code management, codeblocks and visual studio as IDE's and gcc 4.8.1 as compiler. Other tools are DOS batch commands and python scripts, notepad++, and pgn-extract, very sleepy and gcc for profiling, cutechess-cli and winboard for game testing, CLOP-cutechess-cli for auto-tuning, Arena and winboard gui for feature and game debugging, ordo, elostat and bayeselo for rating.

[Ferdy]

One more Windows performance monitor program, to check memory leaks.

[Roman Hartmann]

I'm going to have a look at git then. My understanding was always that git is useful if several programmers are working on the same project so I never bothered to look at git in the past. But having rewritten the basics of my engine completely just recently this seems the right time to start with git before I clutter my code with all the nonsense stuff I'm going to try.

Roman

[vittyvirus]

I use notepad++ and ms vc++ 2010...