Good Practices for development team in large projects

Question

Since I started learning C a few years ago, I have never been a part of a team that worked on a project. I am very interested to know what are the best practices for writing large projects in C.

One of the things I want to know, is when (not how) do I split my project into different source files? My previous experience is with writing a header-source duo (the functions defined in the header are written in the source).

I want to know what are the best practices for splitting a project, and some pointers on important things when writing a project as part of a team?

Answer 1

This is how I code in C(be it solo or in a group):

step 1. Understand the project
step 2. break the project into modules(each module has a separate folder)
step 3. break the modules into sub-modules(each sub-module is a .c/.h file pair)
step 4. write a manually desined "make" script. This step sounds ridiculous but it helps. Trust me.
step 5. learn to use a version control system
step 6. test-modify-debug-release. Release early and release often
step 7. think of improvements to the existing code
step 8. go back to the drawing board. 

For example(very crude, off the top of my head example):

You're designing an elevator simulation program. 
STEP1: Understand. [we got floors, floors can have people, people press buttons.. etc]
MODULES: 
      AI-Module[double-elevator single switch requires AI algos to decide which request is going to be addressed first and which elevator will service the request, depending upon the current position of both elevators]
     Interior-Electronics Module[To handle inter-elevator requests]
     Exterior-Electronics Module[To handle external-elevator requests]
     Human-Simulator Module[To simulate humans inside/outside the elevator(required to check overload)]

SUB_MODULES:
     AI-Module/ai.c, AI-Module/ai.h, AI-Module/decision_engine.c, AI-MODULE/decision_engine.h
     Interior-Electronics/press_button.c,Interior-Electronics/press_button.h, Interior-Electronics/delegates.c, Interior-Electronics/delegates.h
     Exterior-Electronics/press_button.c,Exterior-Electronics/press_button.h, Exterior-Electronics/delegates.c, Exterior-Electronics/delegates.h
     Human-Simulator/human_sim.c, Human-Simulator/human_sim.h
     ./manager.c ./manager.h ./main.c

And the steps follow :-)

Answer 2

One of the most important things beside coding guidelines, versioning control systems, workflows and a lot of coffee is:

Communication.

You and your team members have to communicate with each other. Regardless if the question might be stupid, ask if in doubt. Talk if in doubt. Talk if not in doubt. Talk, talk, talk.

Having function prototypes and data structures in your header and the code in the source file is always a good idea. For even more structure you could split some aspects of your projects in subprojects (if desired).

And of course a bugtracker and ticket systems like Redmine or Bugzilla is highly recommended.

Answer 3

C Modularization

There is a classic paper on modularization called "On the Criteria to be used in Decomposing Systems Into Modules." Briefly summarized, the criteria are to make a data oriented, not functionally oriented decomposition of your project, and to use metrics to judge the success by how few modules must be touched per enhancement.

C is a structured programming language and some key concepts include creating low coupling (by avoiding globals and using parameters) and high cohesion (by grouping closely related functions and data together).

For C, what you describe for separating the .h (declaration) from the .c (definition, also called implementation) is good. Some practical considerations arise with .c/.h files, but generally .h files should include very few global variables (i.e. externs) and prototypes for only those functions that will be used outside the .c.

There are many C programmers who talk don't use structured analysis or design. Best Practices once involved making a Structure diagram that broke the problem a program was designed to solve into a top-down functional decomposition, that was transformed into a tree of modules using a technique called transform analysis. This is no longer considered best practice, because data oriented and object oriented decomposition has proven itself superior. However, C programmers often find what they do is a tough fit for object oriented design because the language features don't line up.

Team Best Practices

This is the subject of entire books. Watts Humphrey wrote a technical report called "The Team Software Process" that is a classic and a free download. Skim over just pages 4-6, and 15 to get a really fast overview of what is important for the team and its leadership. Other parts of the document also tell you a lot about the expectations of planned methodologies in terms of documentation including productivity and quality measurement.

Your team may pick a life cycle model that is either planned (more traditional waterfall, spiral, or feature oriented development) or Agile (iterative/incremental or perhaps lean). Both will have many processes that overlap, although they might not be practiced exactly the same: documentation, source control, integrated tracking and planning with databases and chart editors, testing, and some kind of peer review.

If you think

We are uncovering better ways of developing software by doing it and helping others do it.

you should consider what the Agile guys are saying because team process centered around Scrum or eXtreme Programming (XP), is later and reacts to what people felt didn't work before.

Answer 4

Important thing to mention is a team spirit, communication and approach to eliminate the technical dept/gap that team members may know/have. Here you are some suggestions that you may consider and follow:

• Bring a continual flow of new knowledge in. Once a week you should have somebody from outside come and speak for an hour on a technical topic. Provide food, and make an effort to get good speakers. Bring in people from your sister development organization and from completely outside your company or different project. When you bring people in, ask them who is doing the most interesting work related to your project or area of expertise. This process will help build knowledge and skills into your group and will eventually get you connected to the world experts in whatever you are doing.

• Have you own team members speak at least once or twice a month. If you are constantly researching best practices and you are successful, you will eventually be asking for more resources or asking a development team to adopt your work. The more people you have who can speak articulately about the work, the greater your chance of success.

• Have short, frequent meetings whose primary goal is to keep the whole team connected. When I was running a group of 6 to 8 people building a compiler, we met twice a week for 45 to 90 minutes. Everybody including me, talked about what have you done since the last meeting, what do you hope to achieve by the next meeting, and what is the next step you will take today (aka, Scrum methodology of daily stand-up meetings). These meetings served three purposes:

  1. Kept everybody on the team aware of the big picture.

  2. Enabled the junior people to learn from the senior people.

  3. Got people unstuck quickly, before they went off the rails.

It's a great privilege to be in a big team, learn good practices from each other and to have some say in setting your own direction!

Answer 5

When to split your C source code in multiple files:

• When the compile time starts slowing you down. Usually your compiler only builds the source files that have changed. If you put everything in a c+h duo, then the compiler will always compile it all.
• When you work with more than one developer concurrently on the same project. Whether you use a version control system or not, it is not convenient when two developers want to edit the same source file. This is strong reason to group your functions in parts that belong together and split into separate files accordingly.