Home Man
Search
Today's Posts
Register

Discuss whatever is on your mind. New members can introduce themselves. Talk or comment about any topic that's on your mind..

Naive coding...

Tags
discussion, discussions, software development

👤 Login to reply

 
Thread Tools Search this Thread
# 1  
Old 02-18-2017
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......
# 2  
Old 02-18-2017
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.
The Following User Says Thank You to Don Cragun For This Useful Post:
wisecracker (02-19-2017)
# 3  
Old 02-19-2017
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 02-19-2017
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.
# 5  
Old 02-19-2017
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.
# 6  
Old 02-22-2017
Quote:
Originally Posted by wisecracker
"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.
# 7  
Old 02-22-2017
Quote:
Originally Posted by wisecracker
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.
👤 Login to reply

« Previous Thread | Next Thread »
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

More UNIX and Linux Forum Topics You Might Find Helpful
Thread Thread Starter Forum Replies Last Post
php: Need little help in Coding AimyThomas Programming 2 09-26-2012 07:51 AM
Need help with coding crazydude80 Windows & DOS: Issues & Discussions 2 03-26-2012 06:29 PM
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
pro*c coding user71408 UNIX for Dummies Questions & Answers 1 03-25-2008 05:52 AM
sed coding rita1985 UNIX for Dummies Questions & Answers 1 01-28-2008 11:23 PM


All times are GMT -4. The time now is 01:25 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
UNIX.COM Login
Username:
Password:  
Show Password