LinuxQuestions.org
Review your favorite Linux distribution.
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-24-2017, 06:16 AM   #16
wpeckham
Senior Member
 
Registered: Apr 2010
Location: Continental USA
Distribution: Debian, Ubuntu, Fedora, RedHat, DSL, Puppy, CentOS, Knoppix, Mint-DE, Sparky, Vsido, tinycore, Q4OS
Posts: 2,290

Rep: Reputation: 919Reputation: 919Reputation: 919Reputation: 919Reputation: 919Reputation: 919Reputation: 919Reputation: 919

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!)
 
Old 07-24-2017, 06:46 AM   #17
bloody
Member
 
Registered: Feb 2013
Location: Berlin
Distribution: Gentoo, Debian
Posts: 172

Rep: Reputation: 25
Quote:
Originally Posted by wpeckham View Post
"To a man with only a hammer, the world looks like a box of nails." Pick the right tool for the job.
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'..
 
Old 07-24-2017, 09:14 AM   #18
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 472

Rep: Reputation: 114Reputation: 114
Quote:
Originally Posted by Keith Hedger View Post
Lurdis I don't often agree with what you say but in this case you hit the nail right on the head!
+Lots
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.

Quote:
Originally Posted by wpeckham View Post
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.)
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...

Last edited by Luridis; 07-24-2017 at 09:17 AM.
 
Old 07-24-2017, 10:40 AM   #19
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,444
Blog Entries: 4

Rep: Reputation: 2896Reputation: 2896Reputation: 2896Reputation: 2896Reputation: 2896Reputation: 2896Reputation: 2896Reputation: 2896Reputation: 2896Reputation: 2896Reputation: 2896
Quote:
Rule #11: There Are No Rules.
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.)

Last edited by sundialsvcs; 07-24-2017 at 10:44 AM.
 
Old 07-24-2017, 12:41 PM   #20
dugan
LQ Guru
 
Registered: Nov 2003
Location: Canada
Distribution: Slackware
Posts: 7,504

Rep: Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866
Quote:
1. Minimum dependencies (as minimum as possible)
Nope. This is the exact opposite of what a good programmer does. Now let's look at your reasoning...

Quote:
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!
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"?

Last edited by dugan; 07-24-2017 at 01:29 PM.
 
Old 07-24-2017, 02:32 PM   #21
dugan
LQ Guru
 
Registered: Nov 2003
Location: Canada
Distribution: Slackware
Posts: 7,504

Rep: Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866
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)
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)

Last edited by dugan; 07-24-2017 at 06:28 PM.
 
Old 07-24-2017, 03:08 PM   #22
scasey
Member
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 5.11
Posts: 332

Rep: Reputation: 121Reputation: 121
Quote:
Originally Posted by dugan View Post
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"?
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.
 
Old 07-24-2017, 03:12 PM   #23
dugan
LQ Guru
 
Registered: Nov 2003
Location: Canada
Distribution: Slackware
Posts: 7,504

Rep: Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866
Quote:
Originally Posted by scasey View Post
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.
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.

Last edited by dugan; 07-24-2017 at 03:24 PM.
 
Old 07-24-2017, 03:43 PM   #24
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 472

Rep: Reputation: 114Reputation: 114
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.
 
Old 07-24-2017, 06:26 PM   #25
Shadow_7
Senior Member
 
Registered: Feb 2003
Distribution: debian
Posts: 3,167
Blog Entries: 1

Rep: Reputation: 674Reputation: 674Reputation: 674Reputation: 674Reputation: 674Reputation: 674
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.
 
Old 07-25-2017, 02:52 AM   #26
Xeratul
Senior Member
 
Registered: Jun 2006
Location: UNIX
Distribution: FreeBSD
Posts: 2,357

Original Poster
Rep: Reputation: 211Reputation: 211Reputation: 211
Quote:
Originally Posted by dugan View Post
(...)
Programming the good Unix way is good and some aspects are well described in this video about free software fundation:
https://vimeo.com/221534566
 
Old 07-25-2017, 06:06 AM   #27
hazel
Senior Member
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: Debian, Crux, LFS, AntiX, NuTyX
Posts: 1,253
Blog Entries: 1

Rep: Reputation: 573Reputation: 573Reputation: 573Reputation: 573Reputation: 573Reputation: 573
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.
 
Old 07-25-2017, 09:23 AM   #28
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: SlackwareŽ
Posts: 12,807
Blog Entries: 27

Rep: Reputation: 2103Reputation: 2103Reputation: 2103Reputation: 2103Reputation: 2103Reputation: 2103Reputation: 2103Reputation: 2103Reputation: 2103Reputation: 2103Reputation: 2103
Member response

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!
 
Old 07-25-2017, 11:46 AM   #29
Xeratul
Senior Member
 
Registered: Jun 2006
Location: UNIX
Distribution: FreeBSD
Posts: 2,357

Original Poster
Rep: Reputation: 211Reputation: 211Reputation: 211
Quote:
Originally Posted by hazel View Post
I was told at university that the most important rule of programming is to make programs self-documenting.

"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.
 
Old 07-25-2017, 12:20 PM   #30
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 472

Rep: Reputation: 114Reputation: 114
Quote:
Originally Posted by Xeratul View Post
"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".

Last edited by Luridis; 07-25-2017 at 12:24 PM.
 
  


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 10:59 AM
I Look for a good programme of the networks finsh Linux - Networking 2 02-24-2008 01:33 AM
LXer: Ten BY TEN. India's IT & BPO Outsourcing. LXer Syndicated Linux News 0 12-26-2005 03:31 PM

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

All times are GMT -5. The time now is 09:59 AM.

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