I also disagree with those ten rules. In any valid rule set #1 should be "never start coding before your design framework is complete". In many cases, you should not code until the entire design is complete, but my experience is that you do not always have that as an option. Coding before the requirement is well defined is likely to waste time and effort, but more subtly may result in code that works but is not optimal for the final design. ((perhaps resulting in support consequences down the road.)

Portability is nice if you are coding an application that must port. If you are coding a driver for a device to run only on the Raspberry Pie III for hardware of your own design and only with a specific Rasp OS, of what value is portability?

"To a man with only a hammer, the world looks like a box of nails." Pick the right tool for the job. If you are a versatile coder you have many tools in your kit. Code in the tool that is optimal for solving the problem (and maintaining the result), not just whatever is in "style" today. (This depends upon your ability to CHOOSE your tool. I have seen managers REQUIRE a language because it was featured in the last tech magazine they read. Some managers should not be allowed magazines!)

Exactly. If you need to support legacy computers, use autotools. If you're just writing consumer software, Scons' dependency on Python ain't as bad as it sounds, as you'll find it mandatory for virtually any recent server or desktop to be installed already, and Python for Windows is also easily installed (although i have other issues with Scons). If you write software to be compiled by system bootstrappers, try to stick to a simple Makefile. If you're doing C++ (with far fewer libc cross-platform issues to be dealt with), CMake really ain't that bad.

And by the way, when this cabal nightmare is over and our ET friends finally show up, they're gonna show us their operating systems & softwares, and everything we ever developed here on earth will be rendered obsolete overnight anyway! Imagine, all the trouble for nothing..

Just sayin'..

Well, I did say I had strong opinions. Of course, that doesn't mean they're always correct, or even most of the time. Peoples out here do lots of strange things in free software. I'm also relatively certain that they believe what they're doing is either correct, or that what they are doing is all they can do. I just wish they'd look at whether what they're doing is absolutely necessary before jumping off the cliff.

For instance, I don't know what the story is behind it. But, I know that 2 forks of ffmpeg is not a good thing from an engineering standpoint. It may be was was required so smooth over some bruised egos somewhere, but it seems like it would be a better decision to put personal feelings aside in the face of splitting up work on something that large.

What you're describing is the "carpenter's house" phenomenon. If you ask me, most of the high-level open source world looks exactly like a carpenter's house: grand in scope and ambition, and perpetually both unfinished and jury-rigged in places.

It doesn't seem to occur to anyone to reduce the scope, finish whatever it is and make extension a new project. It also doesn't seem to occur to anyone that sometimes, throwing out code is a good thing. If you're garage is a mess, you start by taking out everything. After that, tossing out the rubbish is usually your first step...

You'll think that there are "rules" only when you are accustomed to writing new software from scratch – which is almost never done. You are almost always working on a "legacy" application that might be twenty years old, and that has grown organically from whatever design it may have once had. (A "legacy" application that might be grossing $10 million in sales every month, so don't even think of 'rewriting it.'")

No, this is not "an abnormal situation." Software is extremely valuable and extremely expensive. (You(!) are expensive!) The business-risk associated with it is basically "off the chart, all the time." And these are the conditions under which you work. If you can't stand the heat, get out of the boiler room.

(But, more or less, these are what face all "engineers" face, even when the thing that is being engineered is completely intangible, like software.)

Nope. This is the exact opposite of what a good programmer does. Now let's look at your reasoning...

I think you're missing something.

If a program isn't compilable after 5-10 years, that would imply that it wasn't maintained during that time.

If no-one's updated a a program for 5-10 years, then, well, were the program and the programmer(s) responsible for it actually "good"?

Have you thought about why this might be (or more likely, might have been) important at NASA?

Do you think it might be because NASA actually printed code out on paper as a matter of standard procedure?

(Hint: yes)

It is possible that the answer to that is "Yes" -- I've seen programs run that long without changes in the real world because the requirements for what they did didn't change.

I also feel that there are no "general" rules. A project should, ideally, complete requirements gathering and design before coding begins...but as has been said, that's not always possible.

I believe that each company/shop should have rules for consistency within the organization, and those rules should be strictly followed, but the rules might be different than those in another company or shop.

Yes, that is a very good and key point.

I'm aware that Xeratul's list is intended to guard against future changes to the technical requirements (such as changes to the target platform's library dependencies or display server).

Not saying that his list is the best way to do that, of course.

Dependencies should only be exactly what is needed to achieve the most basic goal of the program. Features that require extra things, should always be made optional. Especially if they're frivolous features.

Requiring me to build libsoup and a ton of other stuff to support a weather widget that isn't even turned on by default in the Mate-Desktop panel is a perfect example of dependency madness. That thing should be in with the rest of the applet packages. Tying it to the panel reminds me of Packard Bell computers in the 90's.

Once I ran into one of these early single board Packard Hell monsters where the modem would not work unless an FDD was connected to the MFM cable from the motherboard. How this is electrically possible in a sane engineering environment is not known to me. But, we (me and the client) verified it in test after test. No floppy ribbon, no dialup process. I was in the Twilight Zone of computer hardware.

Well one page is highly subjective.

Density -- 600x600 dpi (even cheap printers can do this, faxes are 300dpi and have existed for decades)

Size -- 8.5" x 11"
- ( 600 * 8.5 ) x ( 11 * 600 )
-- 5100 x 6600

Font -- 8x15
- ( 5100 / 8 ) x ( 6600 / 15 )
-- 637 characters x 440 characters
--- (x 825 lines of text if the font is only 8px tall)

Also bear in mind that some printers can do 1200x1200 dpi without breaking a sweat, even with 3x3 dots per pixel at 1200dpi for readability and you're still 530 x 687 characters. Make multiple 100 char+ columns and easily 1k lines of code on a single page even if you stretch the font height to double to make it more like traditional fonts. The 5x11 px neep font will fit the entire hier manpage on a single 1080p screen when using Xdmx + Xephyr to divide that screen up and form one really tall xterm.

-----

I wouldn't mind a world where all non-C languages compiled / converted their code base to C before making an executable.

Various styles of programming, not the any are "more correct". I tend to favor fewest lines of code over readability. But even that wont fit on "one page" if you're doing anything complex. I'm not a fan of one program per process, I tend more towards one program per system that you pass parameters to execute the "part" of the process needed at the time. Imagine having to call ffmpeg_${codec} versus passing a parameter. And distros creating separate packages per codec, all of them not installed by default. It would probably be less buggy and better maintained, but what an administrative nightmare.

Programming the good Unix way is good and some aspects are well described in this video about free software fundation:
https://vimeo.com/221534566

I was told at university that the most important rule of programming is to make programs self-documenting. That means informative variable and function names, plenty of comments, proper use of nesting, and clear separation of high-level and low-level code. Functions that deal with concepts should have separate housekeeping functions to deal with the nitty-gritty of implementing those concepts.

If you have to debug a program a year or two after you wrote it, it's like reading a program written by someone else. If it isn't well documented, you can't understand any more how it works.

Hi,

I wholly agree with documentation within the code that allow/follow good code practices. I stated earlier in the thread the program content should be well commented. I have seen code where the author commented so sparsely you did not understand what was going on without stepping through the code yourself. The opposite is where the author just about commented every line of code. Overboard for sure. When I code, my comments for a section or stanza will have a intro comment to give a general description of the intended operations then comments within to scope that area.

I use Slackware Gnu/Linux and AlienBob's(scripts/tools) to help admin my systems. Eric's scripts are some of the best I have ever used. He clearly documents the scripts and you can easily read for understanding or modify to suit since you are clearly given the states or conditions within.

I have written a few programs throughout my life and whenever I go back to patch/re-purpose or even check the code, I was able to see what was going on by reading my comments. Even in my personal toolbox the code snippets are commented throughout so I understand the purpose of the code. Why re-think something when a comment will help you follow to understanding what is going on within.

Hope this helps.
Have fun & enjoy!

"I was told at university that the most important rule of programming is to make programs self-documenting."
you got the point!!

If you have a clean code, you do not need a manual or doc. It is optional.

A clean code does not mean to have comments.

*Only where necessary, to explain what's going on in something unusual. The longer it took you to figure out, the more likely it needs a short //. Other than that, the code should be self-documenting.

int mlcr; <-- Bad

int mainLoopCtr; <-- Good

WTF is mlcr? Machine language carriage return? Mother-lovin character code?

We have figgin auto-completion now, even in stuff like Emacs and Vim. There's no longer any reason to be cryptically brief because you're trying to "save yourself from tunnel carpal".