> > you can't use private
> > variables or private helper functions - everything is effectively global.
> That borders on religious though. You can have the private variables & helper
> functions, you just don't have any way for the compiler to enforce it. A
> programmer that is going to #include every .c file, is going to use that to show
> weakness in the person that uses the private stuff ( i.e. you, because he
> wouldn't be so stupid & you obviously would or you wouldn't have mentioned it ).
> Also build times are only really a problem if you write code that has bugs in
> it, so if you're worried about it then "obviously" your code isn't as good as
> the people that don't care.
> Sounds like this guy is running scared ( well unless you really were a pain in
> the arse to him and didn't realise ), which means you'll take the fall if
> anything goes wrong. Especially if the delays in the project are due to you
> demanding the build system changes.
> People never want to hear that they are wrong, especially in front of their
> boss. It's better to prove what you are saying is right to yourself first,
> instead of having an all out argument. Until you have an easy to use build
> system ( list of source files go in one end, makefile with dependancies comes
> out the other ) then you're going to get resistance to the idea. Management will
> probably see this as a waste of resources, so it has to be done in your own
> time. If you handle problems like that then everyone would win.
Okay - just a quick epilogue to this little dispute: I went to see the MD (sounds a bit bad however it actually wasn't: you see he'd told me specifically to come to him if I found the other programmers were being too restrictive about anything), and showed him a document I had printed out which carefully went through every point this guy had come out with (the malloc thing, the printf thing, the dependancy stuff) and showed him a clear record of why I wasn't doing what this guy claimed.
Today we had another meeting - same guys only with the MD there as well, and went over the points in the Doc I had written - it went MUCH better than Friday and they asked if everything was cool now, and we said we thought yeah everything had been sorted out.
As well as that Document, I did have one other line of defence(! yeah it really did feel like a weapon!) in my bag, which was another document I printed up explaining why compiling everything in one go was such a bad idea, dependancy, compile times being 10 - 50(!) times higher, a copy of the compiler bug, namespace (thanks for the help!)... however I didn't have to use it thank god.
It would only have made the guy even more confrontation anyway, it was only there to use if the guy carried on with his crazy bollocks 'Dave is causing a Sony Technical violation with his code' stance.
However I've sent a copy of ALL the docs to myself on the e-mail system, so they are clearly dated. If they get some massive compiler breakdown and try to make me the fall guy again, I can defend myself and prove that I illustrated the problem to him back in November.
> The worst time I ever had was with someone that was dyslexic, so he really
> didn't care at all about code readability. In fact by making it as unreadable as
> possible he brought you down to his level. The classic is commenting out lines
> of code that aren't needed ( including multiple page long functions ) and then
> checking them in to source control "just in case". Find in files doesn't care
> whether the code is #if'd or commented out & any work you do on the file
> requires you to read the entire thing to work out just which version you're
> supposed to change ( or in my case keep, as I'll dump all the dead wood ).
You learn something old everyday...