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.
Why does that upset you so much? Tell me how disliking a clumsy greedy company constitutes trollin you? Is Mickeysoft your name? Or your religion?
No, my friend, if anyone here is a troll, then it's you. You provoke, if that does not work you start calling names and if that still does not work, well let's try to turn the tables and accuse everyone else to be a troll.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
Okay okay okay
Just a little pinprick
There'll be no more, ahhhhhhh
But you may feel a little sick...
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
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.)
the any key okay
Last Visit: 31-Dec-99 18:00 Last Update: 24-May-17 21:10