LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > General
User Name
Password
General This forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!

Notices


Reply
  Search this Thread
Old 07-22-2017, 11:19 PM   #1
Xeratul
Senior Member
 
Registered: Jun 2006
Location: UNIX
Distribution: FreeBSD
Posts: 2,357

Rep: Reputation: 213Reputation: 213Reputation: 213
The Ten Rules of a Good Programme(r) ?


Hello,

What may the 10 Golden Rules for programming?

Here a first attempt, likely, need to be adapted.

1. Minimum dependencies (as minimum as possible)
2. Smaller code as possible and do not produce bloat.
3. A code shall be readable and destined to humans.
4. The use of { } might have importance for readability
5. Portability, portability,... for any platforms (Mac, MS, BSD, Linux,..).
6. Assembler (for one arch), C or C++ should be highly considered before starting a project
7. ./configure ; make ; make install was, is and will be forever. Make sure that your programme can be easily compiled by an human. A short Makefile is key.
8. Man page - might be but not necessary -
9. Do never mix programming languages, i.e. Python, Java, Perl,.. .it is ugly and non efficient. Avoid System() call.
10. The Golden One: Make sure to have a small programme. Several small programs are better than than a big one.


A code creation shall be made step by step from an easy point of view and improved daily, simplified constantly. The progress of programming shall be a process of natural simplification of the programme. The code shall look smaller and more efficient during programming process. It is better to use your own libraries made from scratch to allow portability. Avoid bloated libraries that will not work after few years due to different versions. Prefer basic X11 to bloated libraries when possible. Smaller code as possible to Avoid System Bloat and Mistakes !!! Minimum dependencies (as minimum as possible) since library versions will change over time and wont be compatible. A created good programme shall be easy to compile after 5-10 years, still! The last law is taking example from MS Windows OS. MS has a big programme running the whole best. This is taking vast amount of memory and make the system slow. believe me. Believe me that the smaller your C programme will be the more efficient it will be. In any case, get a quick check at your processes : ps aux, top or htop, mem,... to see how it performs on cpu usage, memory,... Compilation time is also key. A programme shall be compiled in a good realistic time. The use of pointers should be restricted to max. one level. In C, try to stick to minimum portability by using include string, stdio and stdlib at first and to extend if necessary your included libraries. But really, stick to the minimum, it is really important. Maybe in 10-15 years, you have another platform? You might be then happy about good portability. The shorter the code will be the better, but your own libraries from scratch are welcome since they will extend significantly the portability of your programme to another system.

"No function should be longer than what can be printed on a single sheet of paper (in a standard reference format with one line per statement and one line per declaration.) Typically, this means no more than about 60 lines of code per function." (Src: NASA)

All code must be checked regularly and should pass the analyses with zero warnings.
Attached Files
File Type: pdf Golden-Rules-Programming.pdf (41.0 KB, 16 views)
File Type: txt Golden-Rules-Programming.txt (3.5 KB, 10 views)

Last edited by Xeratul; 07-23-2017 at 12:11 AM.
 
Old 07-23-2017, 09:47 AM   #2
jmccue
Member
 
Registered: Nov 2008
Location: US
Distribution: slackware
Posts: 255

Rep: Reputation: 126Reputation: 126
Quote:
Originally Posted by Xeratul View Post
"No function should be longer than what can be printed on a single sheet of paper (in a standard reference format with one line per statement and one line per declaration.) Typically, this means no more than about 60 lines of code per function." (Src: NASA)
When I started out, I remember an old timer told me this, nice to know were it came from. I remember one time seeing a 20 page nested 'if', all kinds of border line illegal thoughts when through my mind

Another thing he told me was "Learn to forget confidential/personal data you see in files". I always thought was a good rule and I remember some people got in trouble with management when they could not forget and told people what they saw.
 
Old 07-23-2017, 10:24 AM   #3
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: Slackware®
Posts: 12,892
Blog Entries: 27

Rep: Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183
Moderator response

Moved: This thread is more suitable in <Programming> and has been moved accordingly to help your thread/question get the exposure it deserves.
 
Old 07-23-2017, 11:19 AM   #4
hazel
Senior Member
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: Debian, Crux, LFS, AntiX, NuTyX
Posts: 1,446
Blog Entries: 1

Rep: Reputation: 614Reputation: 614Reputation: 614Reputation: 614Reputation: 614Reputation: 614
Writing your own libraries sounds like a reversion to the Microsoft model in which every program comes with its own packaged library .dll files. When I started with Linux and learned about shared libraries, I was really impressed. New code always tends to be buggy code, and having to write a new set of libraries for every program just to get around copyright rules sounded to me like a recipe for trouble. All the standard Linux libraries have been around for so long that they've had most of the bugs knocked out of them. A little bloat seems a small price to pay for so much convenience.

Also having to write everything to interface with X without using a widget library would completely exclude people like me who want to write the odd program to do some job for them and for fun. I would never have started with C if gtk2 hadn't existed.
 
Old 07-23-2017, 12:14 PM   #5
bloody
Member
 
Registered: Feb 2013
Location: Berlin
Distribution: Gentoo, Debian
Posts: 172

Rep: Reputation: 25
Don't write huge mega-genius functions which span over dozens of screen pages. In a few years, you won't be able to remember yourself what's going on because you moved on with other things. And if even you can't fix a bug (or even extend your code for new functionality), then who else?

Keep your code simple and easy to read. Spend some time thinking about how to make the code easily understandable, and you'll enjoy your own code for a much longer time. If you're adding specialties, don't shy away from writing a few code comments about what's exactly going on. Once your sourcecode grows (megabyte(s) of source code), a bloated, poorly documented mess will strongly reduce the fun factor when it comes to adding new features you hadn't thought of yet...

Name your sourcecodes, functions & variables in an understandable way, even if names get a little bit longer. A sourcecode named o13.c with a function named f781() won't help understanding the code very much.

Try to keep modularity in mind. Having everything in your project derive from everything else will create a huge complex knot of code which gets difficult to overhaul or re-design, if need be. Try to build smaller modules with clearly defined interfaces, so an entire module can be re-written from scratch, if needed. Such things happen because you're rarely able to see on day one what kind of features & functionality your software will include in, say, 5 or 10 years..

If you write a library, Doxygen is your friend.

C++ has matured immensely with C++11 and newer versions of that language. Just beautiful. Don't start with any C++ variant older than C++11.

Be careful with IDEs. Sometimes they come up with a huge update and all the sudden your workflow changes or there is something not working as you got used to. Make sure that you keep the option available to use your own build environment, be it CMake or whatever you're using (often a simple Makefile will do with small projects), so you can stay independent of any particular IDE. I always did that and i never regretted it. An IDE is merely a text editor with fancy extras, a debugger and a handful of additional features. No matter how great an IDE might be, i never let it auto-takeover the build environment. This also helps distributing open source projects if they don't require anyone to use a particular IDE to work with..

At least with bigger projects, don't write custom hand-made install/uninstall scripts, as this drives system admins mad. They don't like to read through scripts using tons of hand-crafted rm commands on the root level... let CMake or Autotools deal with that. They're far less likely to accidently delete all the wrong files..
 
Old 07-23-2017, 12:35 PM   #6
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: Slackware®
Posts: 12,892
Blog Entries: 27

Rep: Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183Reputation: 2183
Member response

Hi,

Any code project should be well documented with proper comments to show what is being done. That is so readers(sometimes yourself when returning after a long period away) will be able to see the flow of the project. Be sure your comments are specific and relative to the stanza(s) so you will know what is going on at that point.

You do not need to comment each line but where specifics and need at that point so you know what is happening.
Quote:
"It is one of the most beautiful compensations in life…that no man can sincerely try to help another without helping himself." - Ralph Waldo Emerson
Hope thus helps.
Have fun & enjoy!
 
Old 07-23-2017, 01:56 PM   #7
Xeratul
Senior Member
 
Registered: Jun 2006
Location: UNIX
Distribution: FreeBSD
Posts: 2,357

Original Poster
Rep: Reputation: 213Reputation: 213Reputation: 213
Quote:
Originally Posted by bloody View Post
t CMake or Autotools deal with that. They're far less likely to accidently delete all the wrong files..
cmake and autotools aren't recommended. not a good advice to use them.
 
Old 07-23-2017, 02:02 PM   #8
bloody
Member
 
Registered: Feb 2013
Location: Berlin
Distribution: Gentoo, Debian
Posts: 172

Rep: Reputation: 25
Quote:
Originally Posted by Xeratul View Post
cmake and autotools aren't recommended. not a good advice to use them.
Why not? And what would you recommend instead? Personally, i'm no longer using autotools because of several other reasons, but then, which installer would you go for? Qmake? Scons?
 
Old 07-23-2017, 03:00 PM   #9
Xeratul
Senior Member
 
Registered: Jun 2006
Location: UNIX
Distribution: FreeBSD
Posts: 2,357

Original Poster
Rep: Reputation: 213Reputation: 213Reputation: 213
Quote:
Originally Posted by bloody View Post
Why not? And what would you recommend instead? Personally, i'm no longer using autotools because of several other reasons, but then, which installer would you go for? Qmake? Scons?
Herewith an interesting page to answer your question: http://suckless.org/sucks/ (see #cmake, #autotools same).

I hope that this answer may guide and help you.
 
Old 07-23-2017, 04:16 PM   #10
bloody
Member
 
Registered: Feb 2013
Location: Berlin
Distribution: Gentoo, Debian
Posts: 172

Rep: Reputation: 25
According to that article, gcc & clang both suck, too.. (they even call GCC a "virus"). Now that's a new perspective to me. Given those kind of standards, all computer software probably sucks.. :O

About CMake: the fact that it takes some time building it may be a tad unfortunate, but not a reason to entirely reject it. The only thing is that a user also needs to install CMake to build a software, as compared to autotools which comes kinda self-contained, only requiring a bourne shell and a make. I never really liked that little fact about CMake, but i also couldn't find the perfect alternative build env yet, either. Have you?

Anyway, CMake still beats writing custom shell code snippets for installing/uninstalling one's own software on millions of other user's machines.. that's what i was trying to point out anyway.

Let's keep it at that in order not to bloat this forum thread with off-topics..
 
Old 07-23-2017, 05:33 PM   #11
Xeratul
Senior Member
 
Registered: Jun 2006
Location: UNIX
Distribution: FreeBSD
Posts: 2,357

Original Poster
Rep: Reputation: 213Reputation: 213Reputation: 213
Quote:
Originally Posted by bloody View Post
According to that article, gcc & clang both suck, too.. (they even call GCC a "virus"). Now that's a new perspective to me. Given those kind of standards, all computer software probably sucks.. :O

About CMake: the fact that it takes some time building it may be a tad unfortunate, but not a reason to entirely reject it. The only thing is that a user also needs to install CMake to build a software, as compared to autotools which comes kinda self-contained, only requiring a bourne shell and a make. I never really liked that little fact about CMake, but i also couldn't find the perfect alternative build env yet, either. Have you?

Anyway, CMake still beats writing custom shell code snippets for installing/uninstalling one's own software on millions of other user's machines.. that's what i was trying to point out anyway.

Let's keep it at that in order not to bloat this forum thread with off-topics..
There are few alternatives to GCC. GCC is not great at all, but you may find several good alternatives.

Anyhow if you compile on GTK+, high version, with G++, your whole system will be so, that it will be negligeable what you do.
You will need lot of money to buy a good hardware to compile graphical applications. It won't be that bad, depending on given needs.

Fabrice Bellard has made a possible alternative to GCC.
 
Old 07-23-2017, 07:57 PM   #12
Keith Hedger
Senior Member
 
Registered: Jun 2010
Location: Wiltshire, UK
Distribution: Linux From Scratch, Slackware64, Partedmagic
Posts: 2,473

Rep: Reputation: 618Reputation: 618Reputation: 618Reputation: 618Reputation: 618Reputation: 618
Get the money up front!
 
Old 07-23-2017, 10:00 PM   #13
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 472

Rep: Reputation: 118Reputation: 118
More than 50% of all open source software (not just Linux stuff) violates one or more of those rules. Here's my personal summary opinion of it all...

Some complexity is necessary. Those that argue otherwise are naive at best, horribly thick at worst. Autotools is a great example. Given the diversity of platforms, users and library configurations. Something has to deal with all those #ifdefs, and doing the number of them I see in packages by hand is more likely to lead to errors than an attempt to automate it. Do you really want to do aclocal by hand? What about intltoolize? How many spoken languages are you familiar enough not to tell someone that --verbose will put poop in their toaster instead of lead to a more detailed output? If you go this route, #5 is going to eat up years of your life.

Generalizations are bad, including "all complexity is bad." Which is exactly what I think they're saying over on suckless.org. If that's the case, you're all violating your own rules by using Harvard machines. Get yourself a 6502 or 68000, Von Neumann 4-eva!

What complexity is bad? Needless complexity. And, we certainly have plenty of that. Keep in mind some of this is tongue-in-cheek. If you get butthurted, I won't care.

Programmer: Whine! Autotools is too hard! <stamps foot> I know, lets make a new build system! We'll be heroes!

Maintainer: Whine! Configure/Make is too slow! Sure, it runs all automated on a remote server but still I like to watch and it's sooo slow. I know, lets make a new build system! We'll be heroes!

And so we have: waf, cmake, qmake, ninja, scons, something that began with "y"? Yams, yak, yodel? It's largely dead now. What all this amounts to is pollution that complicates an already complicated ecosystem even further. This problem is even worse when it comes to documentation. Half the stuff I build doesn't have man pages because groff and texinfo simply won't do. (Looks at freedesktop sullenly.) Please stop, you aren't helping.

New Programmer: Whine! C/C++/Go is too hard, why can't we use java/node.js/C# to write low-level system code. I know! We'll make a language that converts into C, and call it Vala!

It converts into C alright. It does such a good job a writing garbage C that Googling for "no vala code accepted" actually produces some funny stuff. I'm surprised it's not made it into GnuTLS yet. Wait, "introspection" probably has to get there first. Oh, the horror.

I could go on and on. I'd like to tell you about how many packages require other packages that really should not but, I'll wheedle it down to two. Why exactly is a bookmark library required to build a window manger (kwin5). Why exactly is a weather applet required to build a desktop panel (mate)? I suspect people just don't know how to do optional dependency anymore.

The bottom line is that The Bizarre often gets too chaotic and we're simply not taking the time to prune properly.

Last edited by Luridis; 07-23-2017 at 10:07 PM.
 
Old 07-24-2017, 05:07 AM   #14
Keith Hedger
Senior Member
 
Registered: Jun 2010
Location: Wiltshire, UK
Distribution: Linux From Scratch, Slackware64, Partedmagic
Posts: 2,473

Rep: Reputation: 618Reputation: 618Reputation: 618Reputation: 618Reputation: 618Reputation: 618
Lurdis I don't often agree with what you say but in this case you hit the nail right on the head!
+Lots
 
Old 07-24-2017, 06:45 AM   #15
pan64
LQ Guru
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 9,797

Rep: Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888
I don't agree with that ten rules. Actually these rules highly depends on the target and the size/functionality. In some cases these rules can be useful, but in general - there is no general 10 rules.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Could this article be retitled "Ten Simple Rules for Getting Help from LQ"? allend General 1 06-13-2012 11:59 AM
I Look for a good programme of the networks finsh Linux - Networking 2 02-24-2008 02:33 AM
LXer: Ten BY TEN. India's IT & BPO Outsourcing. LXer Syndicated Linux News 0 12-26-2005 04:31 PM

LinuxQuestions.org > Forums > Non-*NIX Forums > General

All times are GMT -5. The time now is 09:37 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration