Reading source code.

[S6k9GNh0]

When I work with a project, I figure out what specific language it corresponds too, make the small changes to make sure the project conforms (which increases productivity as far as debugging and such goes), and then I look at a list of logical bugs and features to be fixed and added and start working on those.

I have a seriously hard time working on a project that doesn't conform to a standard.

I don't really have a hard time understanding what some code means though. I can generally pinpoint what standard its from and if its conformant or not.

[kbw]

I stopped using PuTTY after seeing the code. The code was so obscure that could be doing anything.

However, Transmission is just beautiful. And then there's Debian ...

Just because a project is open, doesn't imply it's bad. There's a difference between Software Engineering and Computer Programming. One demands discipline.

[moorecm]

I highly recommend running static analysis tools on any codebase that uses macros. They have many, many possible side effects that can be easily overlooked. The tools can point them out.

[blackcoder41]

static analysis tools?? hmm, that's new to me..

[kbw]

I highly recommend running static analysis tools on any codebase that uses macros.

Why bother?

static analysis tools?? hmm, that's new to me..

Coverity seems pretty good.

[chrisname]

I use cppcheck and clang for static analysis.

[Duthomhas]

I've never really needed to worry about it. The trick is not to do something moronic with macros.

(And when you find someone else's moronic macro, track down all occurrences of it and figure out what it is really supposed to do, then fix it.)

[moorecm]

That approach just doesn't scale well. If you want to create/maintain a large codebase you MUST invest in other tools. Static analysis, valgrind, code coverage, unit tests, etc. are all very valuable.

[Duthomhas]

I didn't disagree. I only said that handling stupid macros is (usually) fairly easy.

[kbw]

If you want to create/maintain a large codebase you MUST invest in other tools.

That is no doubt true, but if you're just reading code you don't need any of that stuff.

[Gaminic]

Is there any reason to use "functional" Macros? (So aside from header guards, version/OS checks, etc. Macros that are actually used inside code.)

[kbw]

Handling bits is best done with some wrapper, macros traditionally. Think of the macros that handle fd_set (in the socket library).

Windows has a bunch of helpful macros all over the place.

I believe C++'s author wasn't very keen on them. And in the 90's the Unix authors were less keen on them too. But like all C and C++ language features, when used correctly, there's no better substitute.

[moorecm]

Yes, there are reasons to use macros (such as code generation, inclusion/exclusion for debug/release builds, avoiding the hits from function calls and inlining, etc.). The problem is that they are often used without this justification. If any other mechanism will do the trick avoid them!

[kbw]

Agreed.

[S6k9GNh0]

My least favorite use of macros is conditional compilation that differs between platforms. For instance, having an implementation for Linux and Windows that's OS specific in the same exact file. I think this should be the job of the build system and I've seen it cause issues (for basic stuff like misnamed macros). It also increases compilation time.

[chrisname]

That's a good point. In small programs I do it with macros, but in larger projects it's implemented in the Makefile.