Grrarrrgh, terrible code - Web Dev Vent Megathread

[Suntoucher]

Shitty code is the absolute worst. The only advantage, as far as I can see, is that it pays my bills, otherwise it's frustrating to work with and everyone with a terribly coded website has one because they can't afford it to be well coded/recoded. So you have to work around the fucker, and the net cost is usually greater than if they just paid for it to be coded well in the first place.

So you're left working with garbage.

Thankfully no one has yet complained as I keep pushing up my hourly rate every couple months.

[yod]

i feel your pain....

[Grasshopperus]

There's also the marginal cost to consider. You can either spend a month (optimistically) redesigning everything from scratch and then another month migrating and testing OR you can spend a month adding some new feature that will make the business more money. There's no contest from the business' point-of-view.

Unfortunately the pain that devs put up with and the inevitable complaints don't outweigh the money.

Like you say, the flipside is that you're gainfully employed and probably pretty indispensable to your client. Rejoice! You've got job security. As soon as they've got a clean codebase they'll need less of your time and could probably replace you with a nub. If anything you should tack on some incredibly obscure (but cool sounding) technology and prepare for retirement.

[mashman]

I feel yer pain too. We were asked to write a system back in August. And I was to start designing it. All of a sudden, the 3rd party contractor is coming in (albeit decent guys), told to down design tools and just start getting on with it. Ugh...

Crap code replaces well thought out code... fingers crossed she holds together :yes: come launch day

[EJK]

Any personal opinions/hints/tips to avoid writing crappy codes?

[Grasshopperus]

Any personal opinions/hints/tips to avoid writing crappy codes?

I think most code eventually winds up being crappy. Someone will have designed it for one purpose and then some new requirement comes along and a new feature is rushed in. Rinse and repeat over a number of years until someone gets pissed-off and starts from scratch again.

Code also become annoying as the technology (Visual Basic, Java, Objective-C ) evolves which may break functionality and introduce new practises. Someone new looks at the code and says "Oh that suxors, I learnt to do that a different way at 'tech"

In a general sense there's heaps of ways to do coding well; validation of input, checking of system call return codes, DB normalisation etc. The thing to be aware of is that there is no such thing as perfect code, or a perfect style, each method has different pros/cons in terms of time spent (development speed), ease of debugging, time to train new team members, maintainabity etc

[Bald Eagle]

Any personal opinions/hints/tips to avoid writing crappy codes?

Read any Microsoft code and then avoid like the plaque and run like hell.

[Gremlin]

Don't seek to write perfect code either. Like most jobs, perfection has to be balanced with delivery. It certainly needs to be functional and data integrity enforced etc. I prefer managing networks to being a code monkey, but basic coding is still used.

[johan]

Steve McConnell's 'Code Complete, Second Edition' is a very good read on the topic.

[Suntoucher]

My rules are write like it has to be read, white space doesn't add much to a page loading time and lord does it make things easy.

And if you HAVE to use absolute positioning, can you still at least put the divs in order, not a mishmash.

Boxes seperating sections would be nice too, even if you use absolute positioning, and if margins/positioning etc are defaults, then you don't need to write them in.

Issues I was fighting with on the last one. It was like they intentionally wrote it so that it couldn't be read by anyone but the author. Ended up having to bin a lot of the code and rewrite a chunk.
And notes! If you're using dynamic code that calls from various places. Just HTML doesn't need notes(unless it's a mishmash that uses obscure ids) but if you're calling from ../xxx/xxx/xxx/xxx/xxx/xxx/johnsdog.php that calls a function from ../xxx/sss/fff/config.php that extends a class, notes would really be nice.

Readability defines good code to me, rather than efficiency. Although efficiency is a close second. If it's neither you have terrible code. If it's both I want your children. I'll find a way.

Edit: And LORD, if you're putting a left position in, don't put a right in too. And don't float everything if you're absolute positioning. It's just pointless code that does nothing but frustrate me.

[pzkpfw]

Issues I was fighting with on the last one. It was like they intentionally wrote it so that it couldn't be read by anyone but the author.


That's why I hate the way most people implement CSS.

Yes, it's all very good the way inheritence of styles works, and it's nice how you can sub-class the style selectors and all that; but geez it's hard sometimes to figure out why that box over there looks that way.

Oh, it's inheriting this style from there because it's a child of that element with that style, except it's in a div with this ID and...

Bah.

I think CSS ends up being worse than "real code" sometimes.

[mashman]

Any personal opinions/hints/tips to avoid writing crappy codes?

Like said above. It's pretty hard to get around with the amount of scope creep that goes on. KISS. Error handling is a must (write an error handler that will send an email to an application error email box listing the error, page, class, module and user name info etc... that way you receive the error before the user realises something is wrong.). Funny when ya phone 'em too :)

Keep it functional/modular (people may disagree). Function does X, meets business rule y etc... Simple, logically named, easy to find modules. (no frilly interfacing etc...)

Nullify all objects once you've finished with them. Don't wait for the garbage collector.

You'll find your own style as you go. Good luck fella...

[yod]

i don't have worry too much with CSS, all our stuff is web apps so it's more about functionality than presentation, good OO, sensible encapsulation (where appropriate) and a strong framework FTW as far as my systems are concerned!

I'm currently rewriting an accounting module and instead of using additional database tables for one particular relationship, the originator stored a serialised array of related data as a fekkin string in one field FFS! :doh:

[Marmoot]

I feel your pain!

Let's just say my main job is similar to fixing patients who have had very bad plastic surgery but with all their money already siphooned by the bad surgeons in the first place. And to make matters worse, often their parents wouldn't consent to the recommended surgery fix because the last surgery was the cause of all the problems.

[sil3nt]

I thought about redesigning my local Thai Boxing clubs' website but some other dude got in first and made this: http://www.wtk.co.nz/

Now it is better than the old version...but only just. I can't quite believe he let this half assed job be published.


And on a completely unrelated note i have a mate getting paid to write PHP when he has never done it before. He googles to find out how to do it! Frustrating as nobody even wants to see what i can do let alone think of hiring me.

[pete376403]

Our new web dev at work showed me this:

http://theoatmeal.com/comics/design_hell

He had some pretty uncomplimentary things to say about his predecessors, too.
On the other hand, he has a job for life, sorting out their shit.

[warewolf]

Break your code up in to small manageable chunks. Don't write a 350-line subroutine that basically does the same thing to 10 elements... normalise it, write a function to do the thing, call it 10 times. Much, much better. Whitespace does cost, in that instance, as it cannot be collapsed and must be scrolled through. Gets extremely tedious and time-consuming to work with.

Of course the smaller chunks can be tested, proven, library-ised and forgotten about.

Comments should describe what is being done (eg "add GST"), not how it's being done ("multiply by 1.15").

The most common style advice is to be consistent - and everyone sharing code on the project should use the same style. Conventions don't matter so much, as long as you follow whichever one you've chosen.

I _hate_ working with crappy, lazy, ignorant coders.

[davebullet]

All old and / or large systems eventually turn into a big ball of mud as described here:
http://www.laputan.org/mud/

Well worth a (geek) read.

[Suntoucher]

All old and / or large systems eventually turn into a big ball of mud as described here:
http://www.laputan.org/mud/

Well worth a (geek) read.

That was actually fantastically read. Tempted to drop my hourly rate but tell clients I will only build sites on the precursor that they first read that.

Then ftp all the images out and bomb the site.

[davebullet]

The worst system I worked on was a life insurance capture application (client / server) that had 1,500 classes - each UI element was subclassed!

Do web developers these days use OO practices? I know various frameworks exist, but wonder whether OO theory is still widespread?

[Kendog]

Crappy code = Code that does not deliver the solution to your customers expectations.

Good code = Any code that delivers the customers expected result.

[Suntoucher]

Crappy code = Code that does not deliver the solution to your customers expectations.

Good code = Any code that delivers the customers expected result.

How far into the future does that extend? Only to the moment they see it, or to the moment they discover Web Dev #2 is going to take 5 hours to do something that should have taken 1 because of Web Dev #1's practises?

Trying to decide whether you're the crappy coder we're talking about.

[imdying]

Don't seek to write perfect code either. Like most jobs, perfection has to be balanced with delivery.Yup, don't over engineer, there's no money in it.


Yes, it's all very good the way inheritence of styles works, and it's nice how you can sub-class the style selectors and all that; but geez it's hard sometimes to figure out why that box over there looks that way.No no no. There are plenty of point n click tools that will tell you exactly how a particular element got it's rules applied. Work smarter, not harder.


And on a completely unrelated note i have a mate getting paid to write PHP when he has never done it before.That's nothing. One guy I know looks after a webhosting companies technical odds and sodds... 8 servers, (2 Apache/MySQL, 5 IIS, 1 MSSQL), 8 different CMS systems (mixture of PHP/ASP/ASP.NET ones)... he looks after the servers, the code, the databases, everything... over 500 sites, and he's knows nothing about operational tasks, has never done a lot of PHP, or PASP, or other even weirder shit... and still gets $150 an hour for the privlege. Sickening ain't it :blink:

[pzkpfw]

No no no. There are plenty of point n click tools that will tell you exactly how a particular element got it's rules applied.

Sure, but that still doesn't make the CSS any easier to edit (with whatever tool) or to add a new rule to or ...

Bad messy CSS is bad messy CSS, regardless of what tool you use to see what it's doing.

(Bad analogy time) It's like how a Doctor might have a new fangled high resolution MRI scan of your guts, to see what that bullet did, but it's still going to be hard for him or her to fix you up.




The worst system I worked on was a life insurance capture application (client / server) that had 1,500 classes - each UI element was subclassed!

That reminds me of a large VB6.0 app I had to support, many many years ago. Absolutely full of stuff like (my memory-fu is weak):

sub EnableButton(Button theButton, Bool enabledOrNot)
theButton.Enabled = enabledOrNot
end sub

Tons and tons of absolutley normal stuff was farmed out into subs and funcs and stuff. Way pointless and meant you had to dig through twice as much code as you should, to trace through what was going on.

[BuzzardNZ]

Any personal opinions/hints/tips to avoid writing crappy codes?

yes, the biggest is DO NOT OUTSOURCE TO INDIA. Those cheap pricks write the worst code. Pay peanuts, get monkeys.

[avgas]

Any personal opinions/hints/tips to avoid writing crappy codes?
Comments are like GOLD!!
Make the code 3 x in length.....I DONT CARE!! JUST ADD COMMENTS!

[avgas]

Meh - you guys complain to much.
Trust me it gets a hell of a lot more worse when you have to have code interface to stuff in the real world.
Embedded loops, broken cases or even a bad pointer means that someone (usually sitting in a comfy office somewhere) pushes a button on a web page and then a train on a site somewhere goes into "runaway" mode.

Consultants are the bane of my life, and could not design an exit out of a cardboard box.

[imdying]

Sure, but that still doesn't make the CSS any easier to edit (with whatever tool) or to add a new rule to or ...

Bad messy CSS is bad messy CSS, regardless of what tool you use to see what it's doing.

(Bad analogy time) It's like how a Doctor might have a new fangled high resolution MRI scan of your guts, to see what that bullet did, but it's still going to be hard for him or her to fix you up.I dunno mate, I never have much trouble fixing that sort of stuff... compared to what I normally do it's a walk in the park.

[gale_wolf]

Crap code and system design is killing me right now. Supporting/maintaining multiple legacy apps and systems where 3rd party controlled PC-connected embedded cryptographic devices have to work across all manner of unreliable networks and that at least 20 previous "rockstar" programmers have all mangled horribly before landing in my lap is causing me to seriously rethink my vocation! I really enjoy programming, but other people's horrid code just serves to make me realise how good my own code is :innocent: