Unix/Linux Go Back    


What is on Your Mind? Come inside and relax a while. Discuss whatever is on your mind. New members can introduce themselves. However, technical Q&A should happen in our other forums.

Naive coding...

What is on Your Mind?


Tags
discussion, software development

Closed    
 
Thread Tools Search this Thread Display Modes
    #1  
Old Unix and Linux 02-18-2017   -   Original Discussion by wisecracker
wisecracker's Unix or Linux Image
wisecracker wisecracker is offline
Registered User
 
Join Date: Jan 2013
Last Activity: 16 June 2018, 3:08 AM EDT
Location: Loughborough
Posts: 1,268
Thanks: 379
Thanked 344 Times in 269 Posts
Naive coding...

"Naive coding."
(Apologies for any typos.)

I came across this phrase a couple of weeks ago and it has made me decide to set off a discussion.

I had never heard of it before but I did some research and discovered that I probably fall into this category.

My phrase is: "I code to work, not work to code!", so therefore I guess when viewing any of my code, pros' must think how primitive some of it looks.

So, what do you guys who code for a living think when you see some attempts of others solving problems and use _brute_force_methods_ for example to solve their coding problems when there are probably more elegant solutions?

Also what is wrong with a naive solution that works for the coder although it may not be anywhere near as fast as another method more obvious to someone else?

The plotting and drawing routines for example on AudioScope can't seem to be done any other way except by _brute_force_...

Comments......
Sponsored Links
    #2  
Old Unix and Linux 02-18-2017   -   Original Discussion by wisecracker
Don Cragun's Unix or Linux Image
Don Cragun Don Cragun is offline Forum Staff  
Administrator
 
Join Date: Jul 2012
Last Activity: 20 June 2018, 9:25 PM EDT
Location: San Jose, CA, USA
Posts: 11,325
Thanks: 640
Thanked 3,944 Times in 3,371 Posts
From the definition of naive, naive programming isn't necessarily bad programming; it just shows that the person writing the code lacks experience, judgement, or wisdom. In many cases naive programming produces code that is just slower than what a more experienced programmer might right, but sometimes the naive code fails miserably.

Suppose you write code to get the month, day, and year to put in a report that you're about to generate and to use as part of the filename for that report. That could naively be done with:


Code:
YYYY=$(date +%Y)
MM=$(date +%m)
DD=$(date +%d)
label="$MM/$DD/$YYYY"
filename="report_${YYYY}_${MM}_${DD}.txt"
...

A more experienced programmer might do the same thing with:


Code:
IAm=${0##*/}
read label filename hour <<-EOF
	$(date '+%m/%d/%Y report_%Y_%m_%d.txt %h')
EOF
if [ ${hour#0} -lt 8 ]
then	printf '%s: This program should not be run before 8am.\n' "$IAm" >&2
	exit 1
fi
...

If you run this program every day at noon, will the label and filename variables be set differently with these code segments? Almost certainly, no.

If you run this program every day in a cron job scheduled to run at one minute before midnight what values might you get for those variables on December 31, 2016 when lots of long-running month-end and year-end reports are running at the same time? With the naive code you could get any one of the following four sets of values for those variables:


Code:
label		filename
==========	========
12/31/2016	report_2016_12_31
12/01/2016	report_2016_12_01
01/01/2016	report_2016_01_01
01/01/2017	report_2017_01_01

Note that the middle two of those will overwrite daily reports from the start of the previous month or year and the last one will be overwritten by the report written at the end of the day on January 1st (unless the mistake is caught sometime during the day on New Year's day). With the more experienced programmer's code, the last three will never happen, but you might get a diagnostic message instead of the wanted report if the code is started late. When the naive programmer is bitten by this, (s)he learns from experience that the code needs to be made more robust and becomes less naive (and learns that you shouldn't schedule cron jobs to run at one minute before midnight if the code that will be run depends on being run before midnight).

Note that naive code can sometimes run faster than well written code, but fail miserably when unexpected (and unchecked) events occur.

Most of the code we write in this forum assumes that data is in the specified format and skips a lot of error checking that should appear in production code. Many of us should be more careful to point out that the sample code we suggest here should be strengthened with appropriate error checking if the code is going to be used in a production environment. Linux
The Following User Says Thank You to Don Cragun For This Useful Post:
wisecracker (02-19-2017)
Sponsored Links
    #3  
Old Unix and Linux 02-19-2017   -   Original Discussion by wisecracker
MadeInGermany's Unix or Linux Image
MadeInGermany MadeInGermany is offline Forum Staff  
Moderator
 
Join Date: May 2012
Last Activity: 20 June 2018, 9:09 PM EDT
Location: Simplicity
Posts: 4,122
Thanks: 357
Thanked 1,401 Times in 1,258 Posts
I use "date with eval" instead of "unsafe" here docs (that denote ugly tmp files).


Code:
eval `date '+YYYY=%Y MM=%m DD=%d'`
label="$MM/$DD/$YYYY"
filename="report_${YYYY}_${MM}_${DD}.txt"

--
You code like you eat.
Fast food makes you fat, and you risk a heart attack.
The Following User Says Thank You to MadeInGermany For This Useful Post:
wisecracker (02-19-2017)
    #4  
Old Unix and Linux 02-19-2017   -   Original Discussion by wisecracker
wisecracker's Unix or Linux Image
wisecracker wisecracker is offline
Registered User
 
Join Date: Jan 2013
Last Activity: 16 June 2018, 3:08 AM EDT
Location: Loughborough
Posts: 1,268
Thanks: 379
Thanked 344 Times in 269 Posts
I have this insane distrust of compilers and interpreters.
So I do what could be called naive coding in most langauages that I know well enough because of this distrust.

This is one example of my naive code and IS actually inside AudioScope.sh.


Code:
read -r -p "Set timebase starting point. From 0 to $scan_end<CR> " -e tbinput
# Ensure the timebase values are set to default before changing.
scan_start=0
scan_jump=1
# Eliminate any keyboard error longhand...
# Ensure a NULL string does NOT exist.
if [ "$tbinput" == "" ]
then
	scan_start=0
	tbinput=0
fi
# Find the length of the inputted string and correct for subscript position.
str_len=$(( ${#tbinput} - 1 ))
# Now check for continuous numerical characters ONLY.
for count in $( seq 0 $str_len )
do
	# Reuse variable _number_ to obtain each character per loop.
	number=${tbinput:$count:1}
	# Now convert the character to a decimal number.
	number=$( printf "%d" \'$number )
	# IF ANY ASCII character exists that is not numerical then reset the scan start point.
	if [ $number -le 47 ]
	then
		scan_start=0
		tbinput=0
	fi
	if [ $number -ge 58 ]
	then
		scan_start=0
		tbinput=0
	fi
done

Derivatives of this have never failed under normal conditions on the langauges I have used so it seems idiot proof.
Would professionals like yourselvs consider this puerile coding?
I have no idea if it is possible to have buffer overrun in bash scripting from a 'read', (input), statement.

On searching a few months ago I found this and I do use this method below on small apps to do the same job but I still use longhand derivatives of the above for more serious stuff.
This seems bullet proof but due to my insane distrust of compilers and interpreters I am not sure...


Code:
read -r -p "Enter a number, between 1 and 10:- " -e LIMIT
# Error check!
case $LIMIT in
	''|*[!0-9]*)	LIMIT=10 ;;
esac
# If number is valid check boundaries here...
# More code...


Last edited by wisecracker; 02-19-2017 at 08:17 AM.. Reason: Change LIMIT to 10.
Sponsored Links
    #5  
Old Unix and Linux 02-19-2017   -   Original Discussion by wisecracker
MadeInGermany's Unix or Linux Image
MadeInGermany MadeInGermany is offline Forum Staff  
Moderator
 
Join Date: May 2012
Last Activity: 20 June 2018, 9:09 PM EDT
Location: Simplicity
Posts: 4,122
Thanks: 357
Thanked 1,401 Times in 1,258 Posts
I don't like the assumption of ASCII codes.
Without it becomes better readable.
Also you are missing a logical OR


Code:
for count in $( seq 0 $str_len )
do
	# Reuse variable _number_ to obtain each character per loop.
	number=${tbinput:$count:1}
	# IF a character is not numerical then reset the scan start point.
	if [[ $number < 0 ]] || [[ $number > 9 ]]
	then
		scan_start=0
		tbinput=0
	fi
done

Then you can optimize even the OR


Code:
if [[ $number != [0-9] ]]

And then it's only a small step to realize that perhaps the whole loop can be replaced.
Sponsored Links
    #6  
Old Unix and Linux 02-22-2017   -   Original Discussion by wisecracker
Corona688's Unix or Linux Image
Corona688 Corona688 is offline Forum Staff  
Mead Rotor
 
Join Date: Aug 2005
Last Activity: 13 June 2018, 6:37 PM EDT
Location: Saskatchewan
Posts: 22,696
Thanks: 1,183
Thanked 4,334 Times in 3,995 Posts
Quote:
Originally Posted by wisecracker View Post
"Naive coding."
(Apologies for any typos.)

I came across this phrase a couple of weeks ago and it has made me decide to set off a discussion.

I had never heard of it before but I did some research and discovered that I probably fall into this category.

My phrase is: "I code to work, not work to code!", so therefore I guess when viewing any of my code, pros' must think how primitive some of it looks.

So, what do you guys who code for a living think when you see some attempts of others solving problems and use _brute_force_methods_ for example to solve their coding problems when there are probably more elegant solutions?
For one-off scripts and things you only do once, nothing wrong with it. You're writing code to solve a problem, and if the problem's solved to your own satisfaction without severe side effects, who cares?

The problem is, coding that way, with no effort to learn further, builds bad habits. Naive methods are not applicable to all situations, or even most situations. If you only have the heavy-duty sledgehammer in your toolbox, you'll break all the smaller nails.
Quote:
Also what is wrong with a naive solution that works for the coder although it may not be anywhere near as fast as another method more obvious to someone else?
You're building audioscope.sh as a teaching tool. You've eschewed many modern features because you consider them hard to read.

I think reducing it to a quarter of its length, could make it easier to read.
Quote:
The plotting and drawing routines for example on AudioScope can't seem to be done any other way except by _brute_force_...
Saying so doesn't make it so. You've fought tooth-and-claw against anyone who tries to optimize it.
Sponsored Links
    #7  
Old Unix and Linux 02-22-2017   -   Original Discussion by wisecracker
Corona688's Unix or Linux Image
Corona688 Corona688 is offline Forum Staff  
Mead Rotor
 
Join Date: Aug 2005
Last Activity: 13 June 2018, 6:37 PM EDT
Location: Saskatchewan
Posts: 22,696
Thanks: 1,183
Thanked 4,334 Times in 3,995 Posts
Quote:
Originally Posted by wisecracker View Post
I have this insane distrust of compilers and interpreters.
So I do what could be called naive coding in most langauages that I know well enough because of this distrust.

This is one example of my naive code and IS actually inside AudioScope.sh.


Code:
read -r -p "Set timebase starting point. From 0 to $scan_end<CR> " -e tbinput
# Ensure the timebase values are set to default before changing.
scan_start=0
scan_jump=1
# Eliminate any keyboard error longhand...
# Ensure a NULL string does NOT exist.
if [ "$tbinput" == "" ]
then
	scan_start=0
	tbinput=0
fi
# Find the length of the inputted string and correct for subscript position.
str_len=$(( ${#tbinput} - 1 ))
# Now check for continuous numerical characters ONLY.
for count in $( seq 0 $str_len )
do
	# Reuse variable _number_ to obtain each character per loop.
	number=${tbinput:$count:1}
	# Now convert the character to a decimal number.
	number=$( printf "%d" \'$number )
	# IF ANY ASCII character exists that is not numerical then reset the scan start point.
	if [ $number -le 47 ]
	then
		scan_start=0
		tbinput=0
	fi
	if [ $number -ge 58 ]
	then
		scan_start=0
		tbinput=0
	fi
done

Derivatives of this have never failed under normal conditions on the langauges I have used so it seems idiot proof.
Would professionals like yourselvs consider this puerile coding?
That's just about the most difficult way possible to solve the problem. I only resort to it when the language features just can't handle it (i.e. needing to build a recursive parser from scratch).

When you find yourself doing this for trivial things, you're definitely overthinking it. Try inverting the problem. What if you looked for exactly one non-numeric character? You only need to find one to prove the string's bad, and if you can't... fait accompli.

One way:


Code:
case "$STR" in 
) echo "Blank" ;;
*[^0-9]*)  echo "Contains non-numeric" ;;
*) echo "Valid" ;;
esac

This is portable across all bourne shells. In BASH, you could reduce it to a single statement.
Sponsored Links
Closed

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Linux More UNIX and Linux Forum Topics You Might Find Helpful
Thread Thread Starter Forum Replies Last Post
Need help with coding crazydude80 Shell Programming and Scripting 1 03-26-2012 06:25 PM
Naive Bayes gizmo87 Homework & Coursework Questions 0 11-15-2011 06:56 PM
can I use this coding w33man UNIX for Advanced & Expert Users 6 03-02-2004 07:49 AM



All times are GMT -4. The time now is 10:52 PM.