Breaking News
Comments
Oldest First | Newest First | Threaded View
Page 1 / 2   >   >>
mishapom
User Rank
Rookie
cin >> isReaderCoder;
mishapom   5/1/2014 12:17:56 PM
printf( "What an awe%s piece of code! I find such coding style %s. A programmer who is %s enough to develop such code should be %sed.\n", isReaderCoder? "some" : "ful", isReaderCoder? "magnificent" : "unreadable", isReaderCoder? "smart" : "inconsiderate", isReaderCoder? "promot" : "replac" );

anon3887601
User Rank
Rookie
C? No!
anon3887601   5/1/2014 1:01:53 PM
NO RATINGS
This man is an APL programmer at heart.

 

 

jonnydoin
User Rank
Blogger
Re: C? No!
jonnydoin   5/1/2014 1:07:43 PM
NO RATINGS
Hi anon3887601, Actually he is a brilliant Embedded Engineer. He ended up taking critical part in core aspects of our hardware and embedded firmware group. - Jonny

betajet
User Rank
CEO
Re: cin >> isReaderCoder;
betajet   5/1/2014 1:39:03 PM
NO RATINGS
Nicely done -- very amusing!  I like the way you slipped "sed" in there.  For those of you unfamiliar with "sed", it's the Unix/GNU "stream editor".  It's a great way to process certain kinds of text, but is pretty much a write-only language.

Sheepdoll
User Rank
Blogger
Re: C? No!
Sheepdoll   5/1/2014 1:42:14 PM
NO RATINGS
% For a moment I thought perhaps this programmer was a postscript programmer.  We use lots of % as these are comments.

% Normally I code my lashups in postscript. This last week I have been coding in C.  Must remember to put the ifs and elses at the top of the bracketed {} blocks not the bottoms.  << and >> are used to denote dictionary structures.

% Perhaps this is why I prefer AVR ASM for embedded.  It feels really strange to use C on an 8 bit micro with only 2K of SRAM.  printf and fprintf are not the best solution in such a limited environment.

betajet
User Rank
CEO
Re: C? No!
betajet   5/1/2014 1:43:25 PM
NO RATINGS
anon wrote: This man is an APL programmer at heart.

I'd say more likely a LISP programmer at heart.  The LISP conditional expression is COND, which is a superset of C's conditional expression.

If this were APL, there'd be a bunch of outer products and none of us would be able to understand it :-)

perl_geek
User Rank
Freelancer
Eschew obfuscation
perl_geek   5/1/2014 5:32:24 PM
There's a place for code like that; the "Obfuscated C" competition, where programmers can get the perversity out of their systems before producing real work.

People acquire all sorts of ideas about what constitutes good code, from all sorts of haphazard sources, but managers should make it clear upfront what constitutes merit. (It took me a while to figure it out, and I ask forgiveness of my victims.)

A program is not just a set of instructions to the compiler, it's an open letter to the next unfortunate who has to maintain it. As long as it does the job in a reasonable time, clarity is the prime virtue. It should be obvious what it's doing, and why.  This can take a surprising amount of work, distilling the essence of the problem's structure and using the most powerful tools available.

One of the unfortunate consequences of CS education is that people feel compelled to recreate compilers and usurp the functions provided by the operating system, presumably to justify the pain of studying them. KISS, dammit!

 

 

BrainiacVI
User Rank
CEO
He followed a Magazine Article on Management
BrainiacVI   5/1/2014 6:01:42 PM
NO RATINGS
I had a (terrible) manager once who insisted one of the programmers on my team recode the three move statements he used to make a string and use sprintf instead.

So we went from three small, fast MOV statements (when compiled) to a slow, interpreted function call that would have added K's of code if it wasn't already used elsewhere.

All for the edict of "One line of code is easier to maintain than three."

ghova
User Rank
Manager
Re: Eschew obfuscation
ghova   5/2/2014 11:17:11 AM
NO RATINGS
Re "clarity is the prime virtue."  Amen - writing turgid code that's "efficient" costs more than it saves.  From a cost-benefit standpoint the optimal program is no faster than adequately fast (C and assembly programmers reading this are probably reaching for the smelling salts).  If future additions makes it unacceptably slow, then and only then do you make an analysis of hot spots and work on those that produce the greatest bang for the buck until the program is again adequate.

Re the manager who wanted three clever lines replaced with one that would be familiar to other readers: they promoted the right guy to manager.

However, the managers referenced, who insist on rewrites to improve clarity, are thin on the ground, at least in my experience (1959 - present).  The ones I've encountered would not take kindly to the programmers taking the time to (in their view) "beautify" code.  And it wouldn't win them any friends among THEIR managers.

Jimmy99Neutron
User Rank
Rookie
Management
Jimmy99Neutron   5/2/2014 12:33:33 PM
NO RATINGS
Firstly, as this person was a subordinate, expectations for his work should be clear, a process is to be followed as it benefits the team, the project and its management and the product ( reduced maintenance, robustness, correctness, etc.).  

Knowing this persons history, the guidelines or standards should have been emphasized.  Tolerating deviations incurs risk, re-work, time/schedule implications, quality and money.  As the Leader of the project you "own" the results.  In no way does this condone the Coders preferences and choices.

Page 1 / 2   >   >>


EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

Steve Wozniak Reacts to Latest iPhone
Max Maxfield
6 comments
Funnily enough, just a few days ago as I pen these words, I was chatting with my wife (Gina the Gorgeous) when she informed me that -- as a kid -- she had never played at making a ...

EDN Staff

11 Summer Vacation Spots for Engineers
EDN Staff
20 comments
This collection of places from technology history, museums, and modern marvels is a roadmap for an engineering adventure that will take you around the world. Here are just a few spots ...

Glen Chenier

Engineers Solve Analog/Digital Problem, Invent Creative Expletives
Glen Chenier
15 comments
- An analog engineer and a digital engineer join forces, use their respective skills, and pull a few bunnies out of a hat to troubleshoot a system with which they are completely ...

Larry Desjardin

Engineers Should Study Finance: 5 Reasons Why
Larry Desjardin
46 comments
I'm a big proponent of engineers learning financial basics. Why? Because engineers are making decisions all the time, in multiple ways. Having a good financial understanding guides these ...

Flash Poll
Top Comments of the Week
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)