[dba-Tech] How to write beautiful code

[Ed Tesiny]

 Most of these disciplines I developed out of self-defense as I was a lone
ranger developer and had to maintain or revisit code that I might have
written years ago.

Totally agree with you here and many of the practices were picked up from
the folks on AccessD and from studying code in books.  Many times when I
was actively programming, databases had to be tweaked maybe a year or two
after going live.  Without these best practices one would have to reinvent
the wheel.

On Fri, Dec 28, 2018 at 3:26 PM Rocky Smolin <rockysmolin at bchacc.com> wrote:

>
> I use long variable and field names.  That's a habit from COBOL days when
> the code, if done right, would read almost like air code.
>
> I use spaces between chunks of code that I liken to paragraphs. And use
> lots
> of one line comments which, in the VBA window come out green.
>
> I use continuation characters so that a line of code never goes off the
> screen to the right so I have to horizontal scroll to the right to see
> what's beyond the display.
>
> And most importantly, I indent religiously especially for nested Dos and
> Ifs.
>
> Most of these disciplines I developed out of self-defense as I was a lone
> ranger developer and had to maintain or revisit code that I might have
> written years ago.
>
> Would you call that beautiful?  How do you define beautiful?
>
> r
>
>
> -----Original Message-----
> From: dba-Tech [mailto:dba-tech-bounces at databaseadvisors.com] On Behalf Of
> Arthur Fuller
> Sent: Friday, December 28, 2018 10:24 AM
> To: Discussion of Hardware and Software issues
> Subject: [dba-Tech] How to write beautiful code
>
> How many of you listers take into consideration whether your code is
> beautiful or not? I confess that I'm a big fan of both beauty and
> refactoring, I liken this process to an artist's sketches that lead
> ultimately to a painting.
> I begin with a sketch, and I use pen and paper because no software I've
> tried compares to what I can accomplish in a few hours with a sketchpad and
> a pencil or pen. I'm over 70, and I no longer even try to keep up with the
> latest developments in software, even within my own specialty, databases.
> I modestly consider myself a pretty good SQL programmer, but have written
> more than a few front ends to databases I've designed and developed. Those
> projects range from being one of 8 members of a team developing a
> health-care system involving 500 tables on 8 servers (for privacy
> considerations, not to mention the physical size of the databases in
> question -- imagine a database that includes the population of Ontario, and
> a related database consisting of all the physicians in Ontario, and the
> necessity of PITA (Point In Time App -- c.f my article on this topic at Red
> Gate's Simple Talk site). In a medical app, you might need to track a
> particular patient and discover who her physician(s) were in 1999, and then
> track their diagnoses and the results they measured -- assuming they
> bothered to follow up. This is not a general accusation of all physicians,
> but there are provably more than a few bad apples in the basket.
> I digress. How many of you listers appreciate the art of beautiful code,
> and how many of that selected set are employed in companies who appreciate
> gorgeous code?
> Another prejudice I readily confess: extensive comments do not compensate
> for gorgeous code. On the other hand, I also believe that every previous
> version ought be commented and included in the source file(s), with
> comments describing why the original code was deemed insuffficent, either
> because it overlooked boundary conditions or simply because there existed
> much quicker algorithms to solve the given problem. Take a simple problem
> such as sorting a million stocks of interest, and analyzing what happend
> since Christmas this year. One day it skyrockets and the next day it
> plummets.
> Yet again I digress, but I'm on a thought train here, and will send this
> and also follow with the second part of this thesis. Returning to the
> subject at hand, all us programmers are going to die soon, and all that
> will be left of us, other than ashes or a hole in the ground, is the code
> we wrote. That's why I demand that the code we write be beautiful. It ought
> to be self-explanatory, so our successors can immediately understand it,
> and take over once we're six feet deep. That is our responsibity, and our
> obligation, and that's why we must write beautiful code. The next
> generation of use senior citizens will need to read our code, and
> understand why we made the decisions we made. And then improve our
> techniques.
>
> --
> Arthur
> _______________________________________________
> dba-Tech mailing list
> dba-Tech at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-tech
> Website: http://www.databaseadvisors.com
>
> _______________________________________________
> dba-Tech mailing list
> dba-Tech at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-tech
> Website: http://www.databaseadvisors.com
>