-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
unmaintainable-code
A more maintainable, easier to share version of the infamous http://mindprod.com/jgloss/unmain.html
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
I wonder how he feels about this now: https://github.com/torvalds/linux/pull/17 where he very enthusiastically argues for 72 characters to a line in commit messages?
I've regularly seen projects absolutely ruin their readability by adhering strictly to a character limit. You see excessive abbreviations, re-definitions of existing objects to create shorter names, line breaks in illogical places, etc.
Oof, I remember being in school and they taught us COBOL for 3 semesters (this was late 1990s...) I had to go look what Github has that's COBOL and this is what I found.
When you're working on a leaf file with few (or no) dependencies, it's easy to keep function names short. Coupled with a 4-column indentation, it's really not that bad. Most of the time you'll get no more than 3 indentations, sometimes 4, for a total of 12-16 columns. That leaves 64-68 columns of actual text, which is not that tiny. Another reason to keep to a strict limit (be it 80 or 120) is when you're measuring your project size by the line of code. Allowing overly long lines would be a bit cheating. Here's an example of a strict 80-column limit. It mostly works for this particular case.