The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions. Or if you must, use the Back Room[^] - but enter at your own risk.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen. For those discussions where you wish to be a little more frank, use the Soapbox[^]
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
Some questions inspired by the earlier "I hate debugging" thread:
Supposing there was a scale from 1 to 10 which ran roughly as follows:
1) Get the damned job done anyway you can. Best practices? Never heard of 'em!
2) Quick and dirty's always done it for me, I try to be as tidy as I can be but I'm not going to fuss about high faluting concepts when my customer just needs a website.
3) I'll brush it up a bit when I'm finished.
4) I try to stick to some kind of decent design pattern but I'm not going to lose any sleep if I violate it here and there.
5) As long as things are done reasonably, that's cool. Yeah, I break a few rules here and there but hey y'know, you've got to be pragmatic.
6) I spend time upfront on design because good design leads to good code but I'm not going to get too obsessed with what the rest of the world does or doesn't deem to be best practice this week.
7) Best practices are worth aspiring to. I don't always use them but I do try hard to stick to the main ones.
8) Rules aren't carved in stone but there needs to be a damned good justification for deviation.
9) OMG! That line isn't covered by a unit test - that makes it LEGACY CODE! And look at that! A singleton! It's a goddamn anti-pattern! I don't feel too well ..
10) The Law of Demeter has been broken and the crops will fail if I don't rewrite the whole damned thing from scratch.
Now, obviously this is a rather arbitrary (and slightly flippant) scale but assuming a general spectrum running from Q&D via pragmatism to extreme perfectionism:
a) Where would you place yourself on the spectrum?
b) Where do you think that you should be on the spectrum?
c) What do you think are acceptable points on the spectrum for others to occupy?
d) Does your position vary according to what you're working on (e.g. is your attitude to a web-site different to your attitude to designing a database? If you write both low and high level code, does your approach change?)
a) Between 7 & 8, probably.
b) Between 7 & 8, probably.
c) Between 0 & 11, probably.
d) No, not really - my personal feeling is "if a job's worth doing, it's worth doing properly". I do not like doing the same tasks repeatedly (one of the -many - reasons I hate mowing the lawn). High and low level aren't as different as you might think, it's just a different environment in which to work - there is a smaller difference between embedded code and a Windows Forms app, than between a Windows Forms app and a website for example.
I try really, really hard not to have to revisit code, but I make it as easy for myself as a can, because I know there will be bugs, will be changes. Doing the right thing now saves me a lot of effort later when I've forgotten why I did something "clever".
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
c) It would vary between different projects and teams. Somewhere in the middle would be good to aim for.
d) Yes. The bigger the code and the more people that would need to maintain the code, the higher up on the scale the project should be. If the code needs to be certified the number should be higher than if the code is to be used by one or two people occasionally. Good design is always a good idea and I wouldn't go below a 4 on the scale. I've seen code where developers add complexities and convolutions just to make the so-called best practice 'work'.
usually working on back room [db] apps, about 8, with justifications:
1. solution must fit business requirements - never visa versa
2. even more must [and as efficiently as possible] fit the physical work flow.
small to medium sized businesses have often developed their own in-house work efficiencies that for capture and reporting don't always fit well with [mostly database] best practices.
(So the question is: the "best practices" are for who? - for mine many are really only "best" for keeping newbies in line until they learn how to fly.)
I think the main two categories for answering this are:
1. sole programmer at company who will never really be replaced.
2. programmer is a part of a team
For 1 - I don't care what the code of the sole programmer looks like. It's his own foot he'll shoot off later anyways. Just make the doggone thing work! In every way, performance, security, everything. I don't want to see your code. I don't even want to smell your code, no matter how stinky it is. But you better be able to fix it fast when it breaks in production or when there is a new Windows API and it breaks or whatever. Fix it and no whining.
For 2 - If i'm going to look at your code and you're going to expect me to do something with it, make it clean. Use patterns, use great variable names, use true OOP and SOLID principles.
And, if I come to you and say, "Hey I need to convert HTML to PDF and you've already done that in the Chupacabra software, right? Can I just get that method from you?" then you better be able to say, "sure, it's in a library just add it in and call ConvertHTMLToPDF(htmlFile) and you are done.*"
And, right, I don't care about rules** even if they're named best practices. However, I do actually care about best practices and code conventions that make my life better. Plus, if you are following what I said in 1 or 2 above then all is good and easy anyways, because it is right.
*That's a true story where I went to someone who had that, but the code was inside his WinForm class. Couldn't be used. Ugh!
Hell there are no rules here. We're trying to do something.
d) Usually I couldn't care less about some interface implementation as long as the overall design is good.
So for the architecture I'm probably a 7 or 8, while for the implementation I'm leaning more towards 3 or 4 or even 2. The implementation should be easy to fix anyway, while the architecture isn't!
Too bad I often find some disposable code all polished up and unit tested while the architecture looks like spaghetti