I hate programming

Ok so that's a bit of a lie. I don't hate programming. I just hate web-programming. Or maybe it's me hating reality, that might be it. Ok, well when we learned how to design software, we were all (or should have been) taught a series of core principles. It's these principles that separate 'our' clean, efficient, meticulous code from that of a hack (who may or may not be brilliant in and of her/her own right -- just not capable of working on a team etc). Whatever. One particular principle that stands out to me relates to hardcoding.


Don't hardcode. Sure there are cases where hardcoding is acceptable/ideal but for the most part (i.e. the majority of web and client applications), there's not a whole lot of need for hardcoding and in fact, hardcoding can get you into a world of pain down the road. Sure, you might think you just finished coding whatever it was you were doing and it's perfect -- until someone comes along and says "hey, can you change to ? thanks!" -- that's when you realize you were dumb and you now have to do do a search/replace-all. Naturally it gets more complicated/tedious if it's not longer a case of search/replace-all. So yeah, hardcoding is generally, non-ideal (besides, it's far more elegant to have a universal algorithm that handles a wide range of scenarios than to be stuck in the box of only one scenario).


Of course there is balance -- we can't go around defining constants for everything (or can we?). That balance is determined by the complexity of the application as well as the expected amount of maintainance to be done down the road. Generally speaking, the complex and/or maintainance-intensive the application, the more likely one will want to make use of abstraction and patterning. After all, what's easier to understand:

or

At a quick glance, they look about the same and without experience, the latter might look more straightforward but in fact, it's the former that is far more easily maintained and built up upon -- not to mention I've simplified the second scenario by not defining exactly what those conditions are. The step that is left out of the first one is the actual translation of the conditions to which scenario it falls under (i.e., such and such results in scenario1, such and such results in scenario2 etc -- this is what the second one only does). The basic principle here is to make your code readable and maintainable down the road when you look at it and you have no idea what you were thinking about when you wrote it the first time. This very basic principle is fairly well observed in application development -- yet when you take the step to web development, it is almost virtually abandoned.

Specifically I'm ranting about ASP.NET development but I imagine a similar rant applies to all the other web application development languages. As I understand it (and I am, by no means, a pro at this), there are three separate areas where we can code.

1. The client-side scripting. Generally Javascript, this is the cohesive goo that gives a website it's 'interactive feel'. Coincidentally, it's also Javascript that gave us the retarded concept that is the popup ad. I have my bias: I hate javascript. Hate it, hate it, hate it (mostly due to popups and the zillions of really stupid scripts out there that totally bog down the Internet  -- which is painfully slow enough as it is). Javascript is a huge rant of rage and anger in and of itself. But that's another day.
2. The back-server side (aka codebehind). This is where you will find your VB.NET/C#.etc code. This is, for all intents and purposes, real code. You define your methods, enumerations, constants, classes what-have-you. This is where work gets done.
3. The front-server side (aka forms). This is where you find the markup for the site. Anyone who has passing familiarity with HTML will feel more at home here. And this is where I have a giant cannon of rage pointed at.

Before moving on, it is definitely worth noting that the back-server side elements can be placed on the front-server side file. In fact, you can essentially copy-paste the codebehind into the front-server file! You do need to encase it with the appropriate tags mind you. Now, excluding obvious scenarios like HelloWorld and your very first ASP.NET homework assignment or something that is exceptionally primative, this is an absolutely retarded notion.

Because noooooo, we couldn't possible have a reason to put VBNET/C# code in a .VB/.CS file like every other VBNET/C# developer on the planet, we need to mash it into .ASPX file. Sure I expect this to happen for basic scenarios but I was particularly ticked when I came across an endless supply of examples of this in a professionally (and I mean that with the greatest respect) example pack ever. Specifically, I'm talking about Obout. Their control pack's example set is phenomenal. It's exceptionally well put together. Except for the insistance of putting back-server code in the front-server file.

Sure. They have a passibly legitimate reason -- when you have a gazillion sample files, you kind of want to keep it at that -- no point doubling the file count for a few lines here and there. Sure. I'll accept that for now: so we'll add "if you have a gazillion files that are all relatively simple, we'll excuse you for not separating the front from the back" to the list of exceptions. So why is it when I search for something to do with ASP.NET and download something to look at it, there is extensive use of this mashing concept? And it's not just "examples" I'm talking about, I'm referring to full out, production oriented thing too!

So what's horribly wrong with the front-end markup? Three things

1. It's friggen HIDEOUS. Have you seen markup? It's a damn mishmash of { } < > % $ and @. Yeah. way to be readable. Oh wait, it's not intended to be readable -- which is why it's markup to begin with! So why the hell would you want to look at it? Let's also not forget that people forget (or don't care to) do spacing and indenting -- you know, to improve readability and all, so you do end up looking at a bunch of random crap.
2. It's unecessarily complicated. Let's say we have a paragraph of text, say 1000 letters long. Our boss has decided on the following color scheme
   
   • Even numbered under 500 characters will be #ff4689
   • Odd characters under 500 will be #5836FE
   • Prime numbered characters will be #1234EE
   • Even numbered over 499 characters will be #FEED86
   • Odd numbered over 499 will be #DEADED
   • The background color of the text for any given letter will be the complementary color.
   Anyone want to fathom a guess of how long the basic html syntax is? (the answer is 61007 characters). This isnt taking into account having to keep track of which letter you're on and whether or not that's a prime or not. Any guesses on how many lines of code? (the answer is a piddly 38 lines and thats without optimizing). Yeah this is a contrived case where it's exceptionally difficult to do it on the front-side ... but I guess that leads to the question of where you draw the line of 'at what point do we recognize that it's stupid to do so much work on the front-side when it's several orders of magnitude easier on the back-side?'
   
3. Now let's say our boss decided to change colors :P Or add new rules. Enjoy.

Sure it might be a bit contrieved here but if you think about it -- it's actually fairly easy as far as 'real world requirements' go. So again, the question of why would you want to mess with the front-side more than plopping down a placeholder or content holder and doing all the work on the back side. Sure, you can make arguements about how javascripting from the front-side is so much easier (see remarks about how much I love javascript) but all of that can be done from the back side anyways and since there is no pre-build syntax checking for javascript anyways, you're not losing out on anything at all.

As for front-side coders -- programming in a static world must be easy. After all you don't ever have to worry about non-hardcoded scenarios.