On the + ! ; youpicksomethingbaby prefix discussion: I'm strongly biased towards not doing it at all. Yes, I hear you when you give the argument for it: 'external sources may need it'. But I won't 'comply' with their apparent crappiness. Yes, I use that word, because I've worked long enough in IT to have found a correlation between 'deteriorated formatting' which requires the _receiver_ to patch things up to make the combo work, and 'deteriorated coding', nay, 'deteriorated architecture and design', which is a major cause for hard to fix bugs in both development /and/ production environments. Where production+bug==triple headache.
In short: I take the offending external input and fix /that/ one. The other way around, which is really saying I am obliged to add some sort of 'recovery hack' prefix to my code to patch up someone else's assumed/expected cruftiness, is adding additional garbage to the already incoming assumed-to-be-garbage[*]. If you don't mind, I'll go and do the entropy thing that way when I'm dead. ;-) [*] They never told me I was working in the garbage processing industry. I always wondered... now this explains why I need noseplugs during the warmer days. For those who reel at this strong opinion: forget my opinion, consider this: if you use such a hack in your code, you may do it because it seems the fastest way out of the conundrum. You're right, of course, but given modern revision control systems, you can have the same speed of development when you clean up the few offenders that made you do this in the first place: external or not, these sources should exist in your repository somewhere anyway (project history management for maintenance) and you can create and track a mainline very cheaply these days, while you 'fix' that missing trailing semicolon in [your branch of] _their_ code file instead of cluttering yours all over the place on a generalized assumption. And, yeah, it's a 'cleanliness of mind' sort of argument. Flip a coin, see what works for you. Fortunately for me, I've found git, which, after a long search and many failures, is my first revision control system in 2+ decades of software development work that actually does have some 'sensible smarts' when it comes to 'track changes' (and merging back branches into main development lines). For my workflow, it is the best, because it does not dictate any 'default layout/process' whatsoever while allowing multiple folks to happily work on the same thing. Anyway, that's my religion. Consider all of them, then pick your own path. Maybe I'll see you in my parish one day, maybe not. Both is fine, just make sure you're happy with what you pick. Cheers, -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [email protected] mobile: +31-6-11 120 978 --------------------------------------------------
