Code was rarely shared and read by others, and teams working on software were small and often consisted of just one person.
Certain habits made sense in those early days and a bit later, too.
Making sure the code was short had some benefits in early computer programs.
So did using short variable names, preferably one or two letters long.
However, as computers became faster and included more memory, programs became more complex.
#Programming languages also evolved to better suit these new, longer, more complex programs.
Teams became larger and collaboration more common.
And the need to maintain code became just as important, if not more important, than writing the code in the first place.
This evolution naturally led to computer code becoming more readable by humans, too.
#Python is one of those “newer” languages and it has readability built into its DNA.
#Python’s syntax makes Python code more similar to plain English than code in most other languages.
But Python goes further than this. It also encourages Python programmers to write neat, readable code. It does this mainly through its style guide, PEP 8 python.org/dev/peps/pep-0…
Not every programmer is entirely on board.
Old habits die hard.
Some programmers still don’t place a high level of importance on how readable computer code is.
And that’s fine.
Defining what’s best when writing code is subjective.
However, the trend seems to be going away from the old style of writing code towards writing code that’s more readable.
Here's a code snippet. Does it make sense? Can you easily understand the code and, importantly, its context?
That code snippet wasn't too tricky.
But compare with this one that does exactly the same thing:
The only difference is the choice of variable names.
Version 2 needs no comments. Version 1 does.
Here's another example. Version 1 with bad variable name choices and other #PEP8 breaches, too
Version 2 (with a bit of overkill, admittedly)
Yes, this is longer, but a lot more readable, a lot less likely to have bugs, and a lot easier to find the bugs if there are any…
…and a lot easier to change in future.
To quote PEP 8
"One of @gvanrossum's key insights is that code is read much more often than it is written
The guidelines provided here are intended to improve the readability of code & make it consistent across the wide spectrum of Python code
As PEP 20 says,#Readability counts
Just as punctuation came into written languages to make them more readable, #programming has been undergoing a similar transition in recent years.
In the case of #readability in coding, it’s not the punctuation marks that make the difference but the #CodingStyle.
I hope this thread was sufficiently readable!
Here's the link back to the top in case you want to share with someone…
In this project, you'll get to use lists, tuples, dictionaries, and sets to set up the grid, colours, and get the balls to bounce and speed across the tiles.
It's fun to write, and fun to watch, too!
2 of 3
If you don't have the time for this but know someone who does, please do share…
The Fourier Transform coincides with the plane of the lens. So small lenses cut out the higher spatial frequencies that are furthest from the centre.
Therefore, these higher frequencies do not go through the lens and they're lost…
[2/n]
So when the remaining frequencies are recombined at the image plane (say the back of the camera or the back of the eye), the terms that are needed for the fine detail are not there…
Now I spend my time:
—> running @codetoday_
—> teaching coding to kids & adults
—> writing articles and books on #coding and #Python
—> creating and running Python courses and workshops (coming soon…)