Programming Is a Very Literary Affair!

Mention programming, and whether you’re outside the field or inside it, people will think of it as a very rational, very complex, very logic-driven thing that has nothing whatever to do with literature.

To outsiders, what programming writes is a pile of gibberish like a book from heaven, densely packed at a glance. Words and symbols jumbled together; look across and there’s an equals sign here, a comma there, then a semicolon, plus square brackets, parentheses and curly braces… all strange and odd, a headache just to look at. Even if you don’t program, you may have heard a friend who does explain: with programming, you can’t get a single punctuation mark wrong! Something that rigid, and you call it literature?!

To insiders, these symbols are no longer meaningless, but they still feel that all day long it’s either if ...else..., or while...do..., for...do... — logical judgements everywhere, and bug to face every day. Something that kills the mood so thoroughly, and you call it literature?!

Programming Is Literature, Of Course!

Programming relies on programming languages.

Since it is a language, how can you say it isn’t literature? Put the emphasis on logical judgements and control flow, and programming is naturally dry and dull — but what happens if you return to the essence of language?

One line of code is one sentence.

A few related lines of code are one passage.

A few related passages of code are one paragraph.

A code file, made up of several paragraphs combined according to a certain structure, is one article.

A module, made up of several code files, is one chapter.

A piece of software, made up of several modules, is one book.

Writing a Book — How Can You Say That Isn’t Literature?

A good programmer considers and reconsiders the naming of variables, wanting the name to convey the meaning at a glance, like a poet weighing each word and phrase over and over;

A good programmer follows conventions even for blank lines, like a writer dividing his article into paragraphs;

A good programmer wants to implement a step in the simplest, clearest way possible, like an author who wants to write sentences that read beautifully, wanting neither to seem long-winded nor to be excessively abstruse.

Plain colloquial prose all the way through is like verbose code that only knows how to use primitive data types and logical conditionals;

Widely understood idioms are like a language’s function library — best when put to use;

Words and phrases that are too obscure are algorithms of excessive complexity and poor readability: two or three of them may convey the meaning, yet others won’t necessarily understand them, and so maintainability is lost. Don’t chase technicality; avoid using them as far as possible.

A well-reasoned article always has a carefully designed structure. Whether by time, by space, or by logical structures such as “general-to-specific”, “specific-to-general” or “general-specific-general”, a good programmer likewise organises and arranges the structure of the code with care.

A good programmer knows that code is written for people to read.

You have to read it yourself, and those who come after you have to read it too.

An ordinary programmer believes that code is written for the computer to execute. So variable names are given at random: a1 and a2 are everywhere, temp1 and temp2 turn up all over the place. To add a feature, they copy and paste long stretches of code and never refactor — the computer executes it perfectly well, the feature is already implemented, so why spend extra effort adjusting the structure to optimise and trim it?

Code That Has No Readability and Cannot Be Maintained Is a Disaster.

It’s like a running-account essay written by a schoolchild. Everything is laid out and everything is made clear — it’s just that something is missing.

What’s missing is a bit of literary soul.

Only by writing code the way you would write a book can you write code well.

Every variable is a character in the book, and you need to give it a name in earnest.

Every blank line is dividing the article into paragraphs; think it through before you press Enter.

When you’ve finished the code, look at the overall structure, adjust it, make it easier for people to understand.

Split files when they should be split, refactor when it’s time to refactor, so that every chapter of this book has a clearer theme.

Programming — what a test it is of a programmer’s literary grounding.

Programming Is a Very Literary Affair!

This article was first published on my WeChat official account “左手编程右手文化” (Left Hand Programs, Right Hand Culture), account ID: devopscd.

Author: Tang Moying

Source: /en/post/code-is-literary

License: this article is shared under "CC BY 4.0". Please credit the author and link back to the original when republishing.