Inputs for Code Review Workshop.

Question

What all aspects should be considered for conducting a code review workshop? It should be generic and 'C' Language based. Both experienced and junior programmers will form the audience.

If a test or hands-on should be included, what can be the format for the same?

Answer 1

Pick out snippets of actual production level code. Anonymize, if this is not an internal workshop, and try to work out issues, beginning with the design and ending at the pedantic worst. A test, however, spoils the mood, for anyone who might be planning to join in.

Answer 2

Before looking at the actual code, start with a high-level overview of the purpose of the code, and how it interacts with other components. That way, people can think about larger architectural issues in addition to line-by-line details.

Answer 3

I firmly believe and would start-off stating, that the practices are for the benefit of the developers and not the organisation. Typically the following are the most general ones I would cover for a workshop. These are language independent and appreciated by an mixed audience and not covered in text books. On a cautionary note, it has been quite some time since I worked on C.

Large scale programming needs which are never properly conveyed and/or ignored until they bite.

Things to do

1. Yes sir, namespaces or simulating them using structures.
2. Physical file organisation & logical file organisation ( how to modularise code)
3. Dependencies among header files and pre-processor directives, also - http://stackoverflow.com/questions/373142/what-techniques-can-be-used-to-speed-up-c-compilation-times
4. Libraries which you would be mandating for project usage (to reinvent or not to reinvent)
5. http://stackoverflow.com/questions/373142/what-techniques-can-be-used-to-speed-up-c-compilation-times/373224#373224

Things not to do

1. Undefined behaviour (QC process can have builds for different platforms!)
2. compiler dependent code
3. macros in user code (kick if you want)

Alternative practices

Please be gentle, as I would be breaking many a rule here. If you are not going to use Raw C, and you have more time in hand you can discuss other non-trivial concerns like auto-conf, forward declarations, smart pointers & RAII, 'actual' namespaces, exceptions :X. Some of the above are very useful aspects available only in C++. The subtle differences between C and C++ also become critical here. However, this section is only applicable if you decide to look beyond standard C.

My take on coding practices is a bit different, I would ask for consistency of style (quantifying which is very difficult). Most organisations do have their own coding practices so not a big concern. I also realise that these may be too late for a code-review, but it is up to you.