+79  Q: 

Am I an idealist?

This is not only a question, this is also a call for help.

Since I started my career as a programmer, I always tried to learn from my mistakes. I worked hard to learn best-practices and while I don't consider myself a C++ expert, I still believe I'm not a beginner either.

I was recently hired into a company for C++ development. There I was told that my way to work was "against the rules" and that I would have to change my mind.

Here are the topics I disagree with my hierarchy (their words):

  • "You should not use separate header files for your different classes. One big header file is both easier to read and faster to compile."
  • "Trying to use different headers is counter-productive : use the same super-set of headers everywhere, and enforce the use #pragma hdrstop to hasten compilation"
  • "You may not use Boost or any other library that uses nested directories to organize its files. Our build-machine doesn't work with nested directories. Moreover, you don't need Boost to create great software."

One might think I'm somehow exaggerated things, but the sad truth is that I didn't. That's their actual words.

I believe that having separate files enhance maintainability and code-correctness and can fasten compilation time by the use of the proper includes.

Have you been in a similar situation? What should I do? I feel like it's actually impossible for me to work that way and day after day, my frustration grows.

+10  A: 

I think your bosses don't know what they're talking about.

If you can, leave that job immediately.

This same attitude made me leave my job and guess what I am still not employed
@satyajit: this doesn't mean everybody (or even most of them) will have the same proble. Anyway, good luck with your job-seeking
I highly recommend looking for another job while at a current job. Use vacation time, then take 2 weeks off between the jobs.
Hamish Grubijan
+45  A: 

start looking for another job, they clearly have no clue.

for bonus points email them this page when you hand in your notice

for the actuall points

  • one big header is almost certainly harder to read and slower to compile assuming multiple headers wouldn't all need to be included everywhere
  • #pragma hdrstop is not portable, and having lots of preprocessor directives throughout the file will impact readability
  • umm fix the build machine then?
Disagree. Single files are significantly faster to compile in GCC than lots of separate files, even when using precompiled headers. But that doesn't mean it is a good reason to do so. Though I am speaking about source files, not header files, I suspect the result might be the same.
assuming incremental builds and low coupling though you should end up with less on average. though point 3 suggests the real issue is their build process sucks
Why not propose to initiate some QIP to improve the quality of work instead - you'd likely gain recognition and respect and you wouldnt have to find a new job.
well the business has to want to change otherwise you are just setting your self up for pain, regardless of who is wrong or right. life is too short, quicker and easier to find a new job.
If having only one file is better for compilation time, you could still maintain separate files and `cat` them together before compilation.
+13  A: 

Mh, I just left University with a Master degree in CS, and before, I had a technical, professional formation towards programming, especially in C++.

Here is my opinion :

  • You should not use separate header files for your different classes. One big header file is both easier to read and faster to compile."

This is totally against the spirit of C++ object programming concepts. The headers define the visibility of your classes regarding the entire project. Stupid.

  • "Trying to use differents headers is counter-productive : use the same super-set of headers everywhere, and enforce the use #pragma hdrstop to fasten compilation"

This has nothing to do with compilation speed. Completely irrelevant. Never heard of a "super-set of headers" this is super-bull**.

  • "You may not use Boost or any other library that uses nested directories to organize its files. Our> build-machine doesn't work with nested directories. Moreover, you don't need Boost to create great softwares."

They're right, programming was created in order to avoid reusing existing code. Who cares about libraries. It's definitely easier to start from scratch every time.

Nicolas C.
Sometimes boost is hard to integrate with. Google allows only the approved boost libraries. Not that Boost is bad, but one has to worry about the risk of having too many things mixed in one place. In a large company there is little flexibility.
Hamish Grubijan
+1  A: 

I am on your side

I think their arguments are just bullshit:

  • Unless they are using pre-compiled header feature, bundling all stuff into 1 big header will never make compilation faster. Even they wanna use pre-compiled header, it is not necessary to put everything into 1 big header

  • Don't forget #include is just like inserting the content into that position. How can having tons of redundant declaration fasten compilation? Their way is "counter-productive" indeed. Productivity is not just compilation speed. Maintainability counts too.

  • It is their build tools that sucks, not boost. Yes, you don't need to use boost to write good software but why ignoring good tools if you can use it?

Adrian Shum
+61  A: 

"Our build machine doesn't work with nested directories" :-)

I agree with your boss.

  • All code should be in a single file ideally.
  • If you have to use multiple files, makes sure you name them with long names to avoid conflicts. Also start filename with a number to keep them in order. The number should be long, to allow future expansion, e.g. usr/src/00000016_mainProg.cpp
  • Never use classes, they split code up into numerous blocks that are hard to keep track of
  • Ideally the whole program should be in a single function.


Sanjay Manohar
"makes sure you name them with long names to avoid conflicts" - better still dont have names at all. file001.cpp, file002.cpp is the best way to organize files. Not just for fun, I have seen such filenames.
`All code should be in a single file`... Sorry i don think it is ideal..
@liaK one file is still too many?
@ jk, Imagine single file that contains 100000 lines of code.. I wish I am not the person who's gonna modify it.. I believe in multiple files..
I think somebody didn't get the irony here...
@liaK ever heard of sarcasm?
I think you mean "Ideally the whole program should be in a single MACRO" for ease of updation.
Ed Guiness
@ klez, Whoof.. I must have been very serious with my own project... :)
@liak - you can resolve that 100000 lines of code issue quite easily. Delete all the line ends and you have only 1 line of code. Also, you've saved some disk space.
I once worked at a couple where we were REQUIRED to give files meaningless, sequence-number names. The justification was that this way if hackers broke into our computer, they wouldn't be able to find the valuable data. They said you should keep a hand-written list of what all the files were. It seemed to me that (a) By the same reasoning, if thieves broke into the building, they could get the handwritten list; and (b) They're assuming that hackers are smart enough to break into the computer system, but don't know how to do text searches for the data they're interested in.
You all forgot one important point: the numbers for files shall be obtained through proper channels, including a review by legal department so that we don't use a trademarked number such as "Forever 21" (TM)
Haha, when I read this I felt like I was on Slashdot. sarcasm_points++
Adam Neal
Not just a single function - a single `for` loop
+115  A: 

You have a problem with authority, Mr. Anderson. You believe you are special, that somehow the rules do not apply to you. Obviously, you are mistaken.

Lol mate, you're not an idealist. Your example shows, that you just cannot bend and go along with the company policy. Regardless of who is right or wrong. Just change the job if you cannot bear it.

You seem to know, what the Matrix is. So it's time to take the red pill now and leave it. Change the job, dude.


AOI Karasu
Thanks for the funny (but true, i guess) answer, and for the reference to matrix: you made me laugh out of my distress ;)
You're welcome :) May sound funny, my opinion is serious, however. :)
AOI Karasu
Even thought it's funny, I think it's a great and valid answer ;)
Breaking the rules is a part of progress.
Helgi Hrafn Gunnarsson

Some interesting links:

Andreas Brinck
@Andreas Brinck: Interesting. I would add that on certain target platforms, including 16-bit DOS and some embedded processors, intra-module variable access and function calls may be faster than extra-module access, but there may be a module size limit. It may be useful to design code so that modules may be arbitrarily grouped (by #include'ing .c files) without naming conflicts, and then join closely-tied modules together as much as possible.
+5  A: 

This is the sad truth in many places. I have been in such situations before (and am in a situation withch is kinda 50% better).

If these are general rules in your workplace, try reasoning out to them with your points. I have been in some situations where the company/department beleived such rules were really true. I was partially successful in proving them wrong. If possible try to have a discussion.

If you are not able to convince them, or they don't want to be convinced, find a new job, but tell them the reason - that they are living in assumptions and don't know what reality is.

Why tell them? Just start a competing business so you can steal all their customers. After all, the customer is always right (although good marketing can get customers to do dumb things)
Wayne Werner
@Wayne Werner: Trust me, if by any means I was able to create a company that can steal clients from a company that makes over € of benefits each year, I would have !
@ereOn: you don't have to steal them all, just whittle them down one by one. Joel didn't steal all the customers from Github and Microsoft's Dynamics CRM, but I would be shocked if he hasn't had some converts.
Wayne Werner
+3  A: 

I totally agree with your bosses!!!

Few things I want to add:

  1. Never use functions, unless they are really needed. In most cases it is totally unnecessary to have other functions than the main function.
  2. In case you need functions write them all in the same file. A program does not need more than one file. This will also reduce the compile time.
  3. A logical conclusion of (2) is that header files are not needed.
  4. Forget about classes / exceptions and other commonly used concepts. They are too complex and will slow down the compiler or will add unnecessary complexity to the program.
  5. ...

I could go on forever, but I think that even your bosses should at this point realize that their complains and arguments for them are as absurd as the things I wrote above.

George B.
+10  A: 

You are an idealist, and idealists are changemakers.

"Influence" and "Initiative" are two key competencies one can have in IT industry. It's not just you can quit your job or go along with it; you can also impose change. Sorry for sounding so Obama-ish. But in your career you'll always bump into people with their own bullshit pragmatism. Never think of quitting before trying your best to improve your conditions. It may not be a one day thing but you can develop a strategy to change things there. You can exploit the weaknesses of their existing standards. You can demonstrate to your bosses the increase of productivity by dropping some of that bullshit. Support your thoughts with academical material, documents, etc. If that too doesn't work, you can quit your job.

If you can change how things happen there, that would be one of the biggest accomplishments in your career and one of the highlights of your resume. I think it's very well worth the shot.

Heard from one colleague: "Inheritance is only used in school, never in real life" Do you still believe they'll be open to change ?
Every company is open to money. And a company is always open to change that brings more money. They just need to be convinced, or see that the change has a direct impact on revenue. You just need to connect the dots properly, push the right buttons for everyone to see it.
Given the above the easiest counterpoint to that is that, no, infact inheritance is widely used by myriad "real life" intitutions (mine for example); there is no end to the wealth of material on the Internet that can back that up. If they refuse to even consider evidence contrary to their point of view then you may have to consider the advice of others here and consider a change in employer.
@ereOn well if they say this `Inheritance is only used in school, never in real life` now you know you are surrounded by people that knows nothing about C++. Leave them, you will not gain any experience staying there, and you will teach them nothing.
Stephane Rolland
+4  A: 

"Am I an idealist ?"

I think that Stroustrup said that the mapping of classes to physical files (source and header files) is one of the least good things about C++.

I agree with you, that my habit is to have different header files for each class.

Having said that, if they want to do it their way, there are probably far more important things to worry about, for example:

  • Whether you/they are implementing the required functionality
  • Whether you want the job
  • How much it would cost them to change their conventions to match your coding style instead of vice versa, etc.

Mapping to source files is just an implementation detail; it's a detail that will be hidden by the preprocessor, the compiler won't even see it.

I don't understand their reasoning; but some developers use primitive tools for finding things in source code (e.g. if using a dumb text editor, finding a class declaration might be easier if the classes are all in the same header file).

partitioning code in to files is not a means of changing the binary but making the code more maintainable
Rune FS
@Rune FS It's not really central to the language though; C++ doesn't require 1-to-1 mapping between logical classes and physical source files (that's just a convention; a good convention usually, but maybe not one that's worth being on the losing end of a fight about): it's more to do with people's programming tools (editors, find-in-files, source control, etc.).
@ChrisW never argued it was :) I was commenting on "Mapping to source files is just an implementation detail; it's a detail that will be hidden by the preprocessor, the compiler won't even see it." it's not even an implementations detail. The sematics stay the same whether in one or multiple files so you need to look for the argument for splitting into several files outside the language I.e. processes and business value
Rune FS
+1  A: 

I suggest you do your homework and make a sound, reasoned argument detailing how changing policies will improve the development environment.

Start with some simple things. Try restructuring some of the large header files into smaller ones, installing a proper incremental build system, and demonstrate how some of the recent changes made by members of your team would have resulted in shorter compilation times.

When you find that Boost provides a good library to perform a particular task, keep track of how much time you need to duplicate the functionality in some other way.

Translate these numbers into dollars. Make a business case to show them that improving practices will lead to money saved.

In addition to that, you can do some research. Find published papers that compare the effectiveness of various coding practices. Look at some of the well-respected C++ authors like Scott Meyers or Herb Sutter. Try to find coding standards in your industry.

If you're armed with the right information and present in a clear, concise manner, they'll listen to you. Always remember though, to be respectful.

Are you suggesting that he refactor the company's source code, using the company's time and equipment, after he has been explicitly told not to?
@ChrisW - No, I would't suggest he violate any company policies. I'm merely suggesting that he work from within to improve his team's coding policies and practices. If he can use his own codebase to build examples his case would be much stronger. If he doesn't have the freedom to access this codebase on his own time, then by all means, he should find other ways.
+3  A: 

I'm constantly amazed at the shortcuts people take in my workplace too. There are'nt such strict rules as you seem to have and the majority of the programmers are top-notch but when I started I couldnt help but think how I could have done something better.

Its something I've learned though: that you don't have time to refactor everyone else's code, acheive 100% coverage with your unit tests and everything else. It's all about 'good enough' code.

Depends on your job really. That attitude when you're dealing with real-time systems, secure data or distributed processing is a recipe for industry-wide disgrace.
If you're dealing with a safety critical system, 'good enough' code still applies but the 'good enough' is much higher :-)
+35  A: 

Somehow the same thing here, but to a lower extent.

Going to work for me is like going to church. Everybody believes but nobody knows.

My not so academic psychological explanation: When things start getting complex the human brain shifts down one gear and enters the "To believe is better than to know" mode. Very dangerous - its like a strong drug, you get addicted quickly and can't get rid of it.

Programmers that are in the "believe" mode for some years are really hard to talk to. They are bullet-proof against all of your facts and arguments because they are surrounded by so much believe that gives them security in their thoughts.

If they have a policy about header files you will have to follow it or otherwise leave the company. On the long run you can (maybe) change their mindset a bit. I had some successes here at my company but not as many as I wanted to.

I'm pragmatic and see your (our) situation as follows:

If they pay you (good) for being at work 9 to 5 and you don't have to do overtime because of their global header strategy, the mastermind build server or any other genius software development method they believe in - your fine for now. But consider, that as a programmer you will not improve. Your ideas will be in conflict with their myths and when the going gets tough, your ideas lose, as good and correct as they may be.

And remember... Do not start to be another believer!!

Good point. I think what you're referring to is just a lack of 'critical thinking'. I know what you mean though its a lot easier to simply go with the flow.
+1 for *Everybody believes but nobody knows*... :)
I think most of us here on SO go to the church of "It's better to know than believe" - which is why we're here and we ask questions. We want to *know* if and why the computer behaves that way.
Wayne Werner
Sounds to me like you're going to the wrong church. You should find one that bases its faith on evidence -- apologetics -- and not just what somebody's parents or teachers told him or what he'd like to believe or what makes him feel good. That applies to both theology and IT.

First, I oppose using the word 'idealist' in this case. Idealist == one who thinks that the ultimate nature of reality is based on mind, or simply, someone who believes in god.

Now, to your question. I don't think they are completely nuts - I can easily imagine how one can value compilation time badly enough to reshuffle all your software into unreadable mess of huge files and homemade basic libraries just to save compile time. From my experience, this approach usually fails, but it's not irrational.

Pavel Radzivilovsky
that's not what idealist means in english.
Matt Ellen
@matt Yes it is. slang you people attached on it, based on "ideals" is ridiculous.
Pavel Radzivilovsky
Language is dynamic, you don't define a word and it stays that way forever. 'Idealism' to most people means something closer to thikning positively or having high ideals.
Belongs to :)
Pavel Radzivilovsky
Lakos's book (which was written a while ago) says that file I/O is what takes most of the time when compiling a large system. Perhaps O/S file system implementations have improved since then, but still.
believing in god and thinking that the ultimate nature of reality is based on mind are not the same things
Matt Ellen
Idealist can mean both someone who's taking a metaphysical position on the nature of reality and someone who hopes/strives for things in life to be "ideal".
+2  A: 

For being in a similar situation:

I was once told not to use Boost, because my employer wanted to be a "Micosoft only" company. They wanted to hear a "really compelling" reason why you use something that in not from Microsoft.

Wow, that's some willful ignorance going on there.
I know the feeling. Took two years to get over that hurdle...
The "only Microsoft" decision was most probably about complexity reduction. With Boost having the reputation of being a tricky library, and Microsoft documentation often being available in German. And probably the mindset: No one gets fired for choosing the market leader's technology.

As all the other answers here should demonstrate to you, there are better employers for you. There are employers you can be proud to work for and to look up to, and maybe most importantly, that you can be happy to learn & grow from. You may want to look around and try to find them.

+5  A: 

Yes, you're an idealist. Good. You'll do more that way (although also experience more frustration...)

Your bosses are ludicrously wrong, but you knew that or you wouldn't have asked. You are working for them, so you have to follow their policies... but you're doing the job better if you change those policies.

The key question is: can you persuade them otherwise? Find out where this policy comes from. (The answer may be 'it just sort of grew up', in which case you'll need to wage a hearts and minds campaign to win over the key people...) Write up some discussion of the flaws. Remember: Business reasons. The reason to change it that will be listened to is never "it's stupid coding practice" but "it reduces our compilation productivity" or "it increases code maintenance costs." Discuss it with your manager and get permission to take it to whichever group's responsible. (Is there any chance you can transfer to, or befriend, the build engine team? Sometimes 'fix it yourself' is an answer.)

If you can't help change policy, or you keep being told not to try - time to start polishing your CV. Bad policies are routine everywhere, but a shop that has no mechanism to improve them won't be able to change when other stuff breaks either - so start looking for other opportunities.

+1  A: 

For what it is worth, I have never worked at a place where I would be 100% happy with the development practicess and process (well, except when I ran my own software company). You always need to adapt somewhat, and if you are lucky maybe they even listen to some of your proposals and improve over time. If not, just start looking elsewhere and be sure to ask the questions about the development practices during the interviews.

Good luck!

Nemanja Trifunovic
+1  A: 

If everything was in the same file where I work, it would be "code delivery hell" where delivering locks the file out for others until it's done (ClearCase). I can just imagine the team of 80 here wanting to deliver changes to a single header/implementation that contains too many things and having to wait in a "delivery queue".

+4  A: 

(a) I certainly agree that putting all your headers in one header file is a very bad idea.

(b) If the companies build process can't handle subdirectories, I'd certainly look into fixing this problem. But as long as the problem exists, to say, "In a perfect world we'd have a build process that could successfully compile my code the way I want to write it, so I'm just going to write it that way even though I know it won't work" is, well, not a very productive attitude. I often think that I wish some language or tool had been designed slightly different, but I don't write code to what I wish the compiler would process, but to what it actually does process.

But my real reaction is, "These are your biggest complaints?! You should be jumping up and down for joy!"

At every job you are goint to have people above you who make decisions, and it inevitably happens that sometimes you think these decisions are poorly thought out. Sometimes the boss is smarter than you think, he knows things you don't, etc, and he is right and you are wrong. Sometimes you are right and the boss is an idiot. Even if you start your own company so you don't technically have a "boss", you have to satisfy your customers, and they will often demand things that you think are bad ideas.

You can always try to convince the boss to do things in what you think is the right way. Depending on the personalities involved and how long you've been with the company, etc etc, you may be able to change policies. Ultimately, if you don't like the rules, get a job somewhere else. But if you quit every job where the boss ever makes a decision you don't like, you're going to spend a lot of time unemployed.

You have to decide what's worth fighting over. Just how miserable does this make your life? How big a deal is it?

Very wise answer I think. To answer your last questions (even if I guess, those are rhetorical): I work with people that can produce ugly code and who don't care because "it's just code". I'm not like them. I tend to enforce rigorness whenever I can (probably too much, yes) and often stay after hours just to make everything (in my code) "perfect". Being forced to do something I know for sure is bad is **really** frustrating to me. However, you're right when you say it is probably the case on a lot of other companies as well. I guess I have to find a why to care less about what I can't change.
I'd love to work some place where all my co-workers were hard-working and capable. Maybe there are such jobs, but I've never found one! A wise man once said, "Don't let the perfect become the enemy of the good." If your workplace is really terrible, sure, move on. But if it's basically pretty good with just a few annoying problems, all you can do is live with it. What's the best you can get? YOu can only find that out through experience. Best wishes. If you find the perfect job, let me know if they have any more openings!
+4  A: 

"Asking programmers to do something without giving a reason is treating them like small children - they ought to be offended by that." - Bjarne Stroustrup

I humbly modify to say a "good reason."

The good programmers leave, thus the dregs stay behind and get to run the "show." It's called the Peter Principle.

+1  A: 

Compilation speed is an issue if you work for a company with a gigantic code base. Entire books have been written on organizing code in the large environments (see Lakos). "Best practices" are guidelines, not hard and fast rules. You have to use your brain when applying them. I don't know enough abuot your situation to say if these company policies are ultimately good or bad, but I can tell you that being consistent with the existing code base is more important than any of your complaints and is itself an important best practice.


Everything is a trade-off. How much time does your company spend every day compiling their code-base? How much time to do programmers spend changing code versus compiling it? How much time do people spend waiting for that big ol' header file to get checked back into CVS so they can add their changes? Are these different uses of time of similar magnitudes?

I'm curious about the emphasis on optimizing compilation time - it's about the last thing that would occur to me but I haven't worked on gargantuan bodies of compiled code. Does anyone have experience with applications for which compilation time was a non-trivial amount of the time spent during a day? What's the longest - versus typical - time spent compiling in the experience of people here?


It seems that fast compilations are the biggest priority for your hierarchy. They are even willing to sacrifice maintenance for this. IMO, they should really reconsider their position and try out cooperative compilation with tools like Incredibuild. In our company, we saved several hours of compilation without having to sacrify the most basic Good Practices.

Seb Killer
+3  A: 

Change your team or change your team

-- Andy Hunt

Troy Bourdon

I'm going to focus on one aspect of this question to keep the answer from getting way too long.

Their claim may be true, but only for FULL BUILDS. During development we avoid full builds because they waste time compiling things that were not affected by the change. The dependency tree in the makefile(s) on the build system are supposed to track that to minimize full builds.

Using a single large header will not speed up build times in every case. Assuming the class bodies are in their own files, each of them will have the master header as a dependency in the makefile. This means when ANY change is made to the master header, all of the dependent object files will need to be recompiled.

Essentially, they are doing a full build every time the master header is touched. Since most C++ build tools treat files as the unit-of-dependency, the object files have to all be dependent on that same master header, thus they all have to be compiled when the header is touched.

If their belief is that a monolithic header is faster, it's because they are using the full-build as their metric. Create two private branches, for testing builds of a monolithic header and another for a divided header, maybe into 10 pieces or so. Make the same change in the header in both branches and then compare build times between the two.

Realize that arguing about the build is less about logic and more about belief or perception. Also, policies like this sometimes have a hidden basis that the team may not openly admit. From what I gather in the question, I'd say that this team doesn't trust complicated build systems in the first place. Telling them to make theirs more complicated (remember, their thinking not yours) will run smack into their disbelief.

Kelly French