[PLUG] Website Programming Philosphy (was: External CSS vs in a <style> tag in the <head> section)

Wed Dec 31 07:31:23 UTC 2008

On Tue, 30 Dec 2008, Tim wrote:

> Date: Tue, 30 Dec 2008 19:37:47 -0800
> From: Tim <tim-pdxlug at sentinelchicken.org>
> Reply-To: "General Linux/UNIX discussion and help;	civil and on-topic"
>     <plug at lists.pdxlinux.org>
> To: "General Linux/UNIX discussion and help\\;	civil and on-topic"
>     <plug at lists.pdxlinux.org>
> Subject: Re: [PLUG] Website Programming Philosphy (was: External CSS vs in
>     	<style> tag in the <head> section)
> 
> Hi Carlos,
>
>> Creating multiple copies of the same code is not good programming
>> practice.  It is better to create a single template, and use
>> programming logic to fill in the dynamic bits.  The moment you have
>> multiple copies of the same code, you have multiple points of
>> maintenance.  The moment you find yourself writing the same thing
>> twoce, you should stop and ask yourself, "How can I make it so I only
>> have to write this once?"  Avoiding duplication is one of the
>> fundamental rules of good programming.
>
> Well, yes, I agree, but there are limits to this.  You have 43 copies of
> the letter 'a' in your last email.  Should you write a method for that?
> This philosphy only goes so far.  I've seen many programs taken too far
> in this direction with dozens of layers of abstraction which accomplish
> nothing except make the code hard to read.  Note that I do security code
> review for a living, so I see *lots* of other peoples' code.  You can't
> account for every possible feature request that comes down the road, and
> Murphy's law indicates the customer will pick the one you didn't think
> of.  There needs to be a balance.
>
> As far as style sheets go, they are already a major step toward
> abstraction of page look & feel.  I haven't seen many sites that have
> more than a couple of dozen styles, if that.  I'm no designer, but if
> you get many more, I'd guess the site might start looking hideous.
> Making them dynamic saves you what?  A few paragraphs of static data
> that you can't as easily ask the browser to cache?
>
> On the flip side, most programmers still haven't figured out how to
> prevent cross-site scripting bugs when they include user-supplied data
> in their pages.  There are indeed ways to inject script into style
> sheets.  Are you allowing user-influenced data to get in there?  Why
> take the risk?
>
> tim

Your letter A example doesn't apply.  This is human readable text,
whereas I was talking about computer code.  One is meant for a human
to read, while the other is meant for a computer.  These are two very
different audiences.  Computers can perform tokenization and
substitution very easily, while humans cannot.  Humans have a hard
time reading dry, repetitous text, while computers don't care.

But let's say for the sake of argument that this weren't a factor.
How could I write a function that would result in less typing than a
single character "A"?  I think a better example be replacing every
occurance of "Kafka" with "K", as Kafka himself did liberally.

A programmer should separate the static from the dynamic.  The static
becomes the template, and the dynamic becomes the raw data.  This is
what a lisp programmer does when writing a macro.  There is a thought
process that allows a programmer to turn segments of repeated code
into a single macro with arguments.  What goes into the body of the
macro, and what becomes the arguments?  Do the arguments consist of
arbitrary executable code?  Especially in the case of a lisp macro,
the answer is often "yes".  It's part of that whole "code that writes
code" thing.

Naturally one has to consider security.  I have heard it said that
security cannot be slapped on as an afterthought; it must be an
integral part of the design.  And certainly it cannot be ignored, for
human nature dictates that any piece of code can and will fall under
attack.  So let's rank security right alongside the other fundamentals
of computer science, as is its rightful place.

Are security and avoidance of code duplication mutually exclusive?  Of
course not, but there is some non-orthagonality there; one can affect
the other, so they must be balanced against one another.  There are
other factors that act upon the structure in the same way, for example
the finiteness of resources.  Having to balance forces that are at
odds with one another, some of which are imposed from the outside by
mischievous humans, is what makes programming an artform.

Since it is an artform, its aesthetic quality ought to be a goal in
its creation.  That's why I get bothered by code duplication; it seems
bereft of artistic sensibility.  I guess that's the truth of why I
take the soapbox and speak against it.  It's a romantic, idealist
point of view.  I don't expect many others to share it.  I don't see
many others sharing it in my day-to-day life at work.  Most people
think of software as a tool to get a job done, and nothing more.  As
long as it does its job, who cares if it is full of copy-and-paste
code, or if it has thousand-line if...then constructs?  Who would even
know?

Carlos