Bad Programming Habits We Secretly Love (infoworld.com) 497
snydeq writes: Breaking the rules can bring a little thrill — and sometimes produce better, more efficient code. From the article: 'The rules are more often guidelines or stylistic suggestions, not hard-and-fast rules that must be obeyed or code death will follow. Sure, your code might be ridiculed, possibly even publicly, but the fact that you're bucking conventions adds a little bit of the thrill to subverting, even inadvertently, what amounts more often than not to the social mores of pleasant code. To make matters more complex, sometimes it's better to break the rules. (Shhhh!) The code comes out cleaner. It may even be faster and simpler.' What bad programming habits can't you (or won't you) break?
You're the problem (Score:5, Insightful)
Re:You're the problem (Score:5, Insightful)
“Any fool can make a rule
And any fool will mind it.”
Thoreau
Re: (Score:3)
âoeAny fool can make a rule And any fool will mind it.â
Only a fool will not attempt to logically circumvent it
... sniff
_____________________________________
live long and prosper
Re:You're the problem (Score:5, Funny)
Re:You're the problem (Score:4, Insightful)
That's only an admonishment against following bad rules. Thoreau practiced a lot of civil disobedience. Hell, he wrote the seminal work on the subject, a little essay titled "Civil Disobedience."
Or, in the words of his contemporary and mentor:
If a rule is bad, change it. But ignoring it while leaving it on the books is poor form.
Re:You're the problem (Score:4, Funny)
Back during Y2K updates to our code base, we'd occasionally have to deal with code written by an ex-employee, who we'll call John. It was so bad that every time someone opened a file he had worked on you'd hear a loud "FUCK! Another John file!" over the cubical walls.
Re: (Score:3, Interesting)
We had a contractor I'll call Paul. He wrote exactly to spec, and not a line more. If you didn't say "protect against buffer overflows when accepting user input" you can guarantee his code would crash if you input a single extra character beyond the prescribed format. It only worked if you did exactly what the user manual described. Any slight deviation and you were screwed, often in ways that were not immediately obvious.
Re:You're the problem (Score:5, Funny)
...who we'll call John...
...a contractor I'll call Paul
Right, so who's going to come up with George and Ringo to make up the full set?
Re: (Score:3)
Half a million Rupees. Paul my ass, we all know he was called Palanduran.
The Issue with programming. (Score:5, Insightful)
We are hired to write new programs/new ways of solving a problem. Rules are made to solve common problems.
If we only follow these rules we are limited to writing programs that have already been written, in that case we are just useless.
If we know when to bend or break the rules, then we can create things that solve problems differently and is new and unique.
When I work with programmers so are hard fixed on the right way to do things, I often get a response that x cannot be done. I break the rule and I have done it in a couple of days work, then they will go but you didn't follow the right form.
The end user doesn't care about form, they care if it Works well, It can be maintained, and it is secure.
Re: (Score:3, Insightful)
You sound are one of the "men of some parts whose cleverness sets them apart from their fellows, but not nearly so far as they imagine."
If we only follow these rules we are limited to writing programs that have already been written...
Non sequitur, and nonsensical. All major programming languages are Turing-complete, and should all be able to express the same statements/programs.
When I work with programmers so are hard fixed on the right way to do things, I often get a response that x cannot be done.
There are things that are impossible in computer science, e.g. solving the Halting Problem. Most programmers tend not to conflate the impossible with the difficult or computationally expensive; your doing so is not a good sign.
Re: (Score:3)
Interesting how many of the "rules" are considered bad form in python (as one example) - and in fact following them is considered ugly, unmaintainable code. Then again, a lot of python rules specifically contradict the rules of everything that came before.
A standard rule in every OOo course is that objects should not expose data, only methods for manipulating data - and the manipulation should be entirely confined to the class. Python considers getters and setters extremely bad form and insists that the var
Re:You're the problem (Score:5, Insightful)
I've heard arguments against writing proper comments similar to what the author makes: "but if you change the code and the documentation or comments don't change, then it might be worse than no documentation at all." My response is that if you're not updating the documentation or comments, then you're not finishing the job you were assigned. You could make the same arguments against taking the time to create meaningful variables and function names.
There's another argument against comments I occasionally hear as well, which is "a competent coder should be able to discern what the code is doing without comments." While that's technically true, it's another argument I would reject. I feel the best comments can and should declare the intent of a block of code, rather than drilling down into the mechanics of the code. Those types of comments are often much more valuable than comments which simply regurgitate the mechanics of code in English.
Still, in my own code, I don't have a fixed ratio of comment to code. It's entirely dependent on the complexity / obviousness of the code in question. For instance, if you have a very simple function, such as a handler that reacts to some UI event and just passes along the event to some other system, or performs a simple operation, it's stupid to spend a bunch of time and create excess visual noise to document that function. A quick glance at the code tells you everything you need to know about what's going on far easier than comment blocks.
On the other hand, when code gets more complex, or the internal workings of a function is less than trivial, I expect to see a more comments in the code. In some of the most complex code I've either written or worked on, the number of lines of comments can actually exceed the number of lines of code. I've even seen some helpful little ASCII drawings in some particularly complex physics code, which was awesome.
Re: (Score:2, Interesting)
My comment about comments in code is that all comments need a date and the coder's initials as a minimum, and old comments should not be deleted. I have way too much experience knowing why these are my comments.
Re: (Score:3)
If you need comments to know who wrote what and on what date, then you need to get your code into source control.
Re: (Score:3)
Re: (Score:3)
Tracking when changes were made, and why, is the job of your source control system. Describing what the code does, is mostly the job of the code; variable names, function names and an occasional brief comment. Describing the expected inputs and outputs of the code is the job of unit testing. Describing the intent of the code, well that's a bit harder to get the right balance. Of course there's lots of overlap, and some huge grey areas.
When reading someone else's code to track down a bug, or add a new featu
Re:You're the problem (Score:4, Insightful)
Exactly. There's a lot of code that needs comments like "fixes bug XXX". If you had to fix a nasty bug and it took you a day to get the details right, let the next poor sap know what you were doing. Otherwise, he's likely to reintroduce the bug by tearing out this apparently useless code.
Another good use of comments is to summarize a large block of code so that people don't have to dig into it to figure out what it does. For example, it's good to document functions at the top with enough detail that somebody would know how and when to call them without having to read through the whole thing.
You need two expressions of intent to detect bugs. (Score:3)
There's another argument against comments I occasionally hear as well, which is "a competent coder should be able to discern what the code is doing without comments." While that's technically true, it's another argument I would reject.
Me, too.
Sure, a competent coder can tell what the code IS DOING. So can a compiler. That's not the issue. What do you do if what the code is doing is the wrong thing? What is the RIGHT thing? If all you've go is the code, you're hosed.
NO process can look at code alone and
Re: (Score:2, Insightful)
There's nothing wrong with GOTOs.
Re: (Score:3, Interesting)
Used judiciously, a goto can save a lot of trouble. The three use cases I have for occasionally using a goto are to break from nested loops, to break from a switch-case within a loop, or as part of error-handling routine where an exception-based approach are not possible or not permitted. In all cases, these are within the scope of a single function.
Re:You're the problem (Score:4, Informative)
There is a theorem that in general, GOTO's can be replaced by WHILE's and flags. What is generally not mentioned is that in the general case, the size of the resulting code grows exponentially in terms of the size of the original code. ;-(
As it happens, we do not get exponential growth for the "break out of the loop" cases...
Re:You're the problem (Score:4, Funny)
yeah, Knuth is always your go to guy...
Re: (Score:3)
An exception is a nonlocal jump, where the destination is in some totally unrelated section of the codebase, typically written by some other programmer even. Everything that's said to be wrong with GOTOs is often said to be right by exception supporters.
Re:You're the problem (Score:4, Insightful)
Re: (Score:3)
10 GOTO 20
15 ? "THIS LINE IS USELESS"
20 RETURN
Yes, yes I did eventually hire professionals. No, no they did not need my help.
Re: (Score:3)
Real programmers use 11101011 (on x86).
Re: (Score:3)
Real programmers use 0001 (on PDP-11)
Re:You're the problem (Score:4, Funny)
"The code comes out cleaner"? (Score:5, Insightful)
If the code comes out cleaner, you didn't break any of my rules. The rule "make the code as clean as possible" trumps all other rules.
Re:"The code comes out cleaner"? (Score:5, Funny)
Does it trump the "make the code work" rule?
Re:"The code comes out cleaner"? (Score:5, Informative)
I would not consider non-working code as clean.
Re:"The code comes out cleaner"? (Score:5, Funny)
Ah, the "No True Clean Code" fallacy.
Re:"The code comes out cleaner"? (Score:5, Insightful)
2) Make the code readable
4) Make the code flexible.
Re:"The code comes out cleaner"? (Score:4, Funny)
1) Make the code work
2) Make the code readable
4) Make the code flexible.
0) Make the code on time
3) ???
5) Make the code - PROFIT!
Re:"The code comes out cleaner"? (Score:5, Interesting)
Having "taking over" a lot of code in my time, I can say for myself, having code that "works and I don't know why" makes me more nervous that code that "doesn't work and I don't know why".
I'd rather have clean code, be it working or non working. If it's clean I can get it to work reasonably quick. If it's not clean and not working then I can easily justify a re-write. But if I can't understand it and it seems to be working, I always have the dread that someday it will break in a disastrous fashion in the most inconvenient of times with me being unable to do anything about it.
Zen (Score:2)
Bingo... the first rule is to be as zen as possible with your programming. Clean and efficient... no bullshit.
Re: (Score:2)
Yeah but none of the suggestions in the OTA actually make the code cleaner.
Re: (Score:2)
Sorry I I have too many threads running in my brain. I meant TFA not OTA.
Re: (Score:3)
Must be a race condition. Did you follow the thread safety rules?
Re: (Score:2)
a=b+c;
If you really needed that comment, turn in your geek badge now.
#3 vastly improves readability in most cases. Trying to read through one statement per line feels like trying to read a book
with
one
word
per
line.
#4 means you don't need to tediously declare every loop variable. I don't care what type "i" has - If the original coder sucks so badly that a simple iterator breaks, I don't keep trying to read their code,
Re: (Score:2)
Re:"The code comes out cleaner"? (Score:5, Insightful)
Re: (Score:2)
It's a tradeoff (Score:5, Insightful)
Sure, you can trade maintainability for efficiency and reliability. People do it all the time. You just have to understand the costs involved. If the efficient code gains you a million dollars in performance, maybe you can afford for it to be crappy code. Or maybe you'll be running the code for 10 years, and if it costs you $250,000 to keep a crusty old engineer on staff who can maintain it, suddenly that million dollars in performance may not be worth it.
<disclaimer>I am a crusty old engineer.</disclaimer>
Re: (Score:3)
If you get the million right now that may be worth spending 2.5 million over ten years, if you're short on cash flow. Going bankrupt is bad.
Re: (Score:3)
I think he's saying that he costs $250K/year.
I'm getting on toward old and crusty, and my cost to the company is certainly closer to $250K/yr than $25K/yr. Dunno what they pay the whelps coming out of school these days, but I never worked for $25K/yr after I got out of school.
Bad Habits? (Score:3)
We ALL fully document our code, have clear specifications before we write code, use meaningful variable names and rely on IDEs...amirite?
In my case, I only program (after doing it for pay for 45+ years) for myself, and I'm creating new stuff all the time, based on experience. For example, my backup strategy. It started out as a simple script to launch Drive Snapshot. It evolved, into having multiple, cascaded backups on one partition of the computer, which are replicated automatically to my main "server" in case the computer dies. Each computer in the office uses the same central repository. It's got bells and whistles that make my job a lot easier when I experiment...if I try some new app and it trashed Windows, I just roll back to last night's backup. (I believe in 100% backups of all computers...including the server...every night, and schedule "fixit/improve it" time first thing in the morning, so I can rollback and lose nothing.)
So, personally, I now break all the rules, and let my needs dictate the code I write. It isn't specified, it's an evolving organism in my small environment.
Oh, and I'm doing all that in cmd files...might consider upgrading to something exotic, like AutoIt, someday, but I've been saying that for four years now...
Re: (Score:3, Funny)
I once saw source code for a library, written in Ada that had the following "feature".
Since Ada code is "self documenting", each routine had a block comment documenting said routine. The block comment was LITERALLY a copy of the routine, commented out...
e.g.:
-- procedure body f is
-- begin
--TEXT_IO.PUT_STRING('Hello world');
--TEXT_IO.PUT_LINE;
-- end f;
procedure body f is
begin
TEXT_IO.PUT_STRING('Hello world');
TEXT_IO.PUT_LINE;
end f;
Copy and Paste. (Score:5, Informative)
Sometimes I will copy and paste a function and just do some minor tweaks were I could have just added a parameter.
Why do I do this? Readability. Having a function called SplitPersonName(string name) and another one called SplitCompanyName(string name) So when I run the function it will be easily readable, as well if there is a bug in one of the fuctions but it works fine for the other. I can just change that one function without having to unit test other parts that could have been effected.
Also I avoid too much Classes that are extended from other classes, that tends to add confusion on where a particular code is being called if you are debugging it from the middle of the class structure.
It is OK to break rules, but you should have a good reason to do so. Also you should feel free to not break the rules when you do not have a good reason to do so.
Re:Copy and Paste. (Score:4, Insightful)
Adding another variant, when you have an existing function that you never expected to reuse part of, suddenly interested in a twist on it. The 'proper' answer is to refactor so that it is shared code, but the code being reused is something that's not changed in 3 years and never had an issue under impressive load. So I could either refactor including changing working code, or duplicate. I'll duplicate. Now my duplicate may break out the relevant code so that if such a circumstance arise later, that the duplication won't happen twice, but I would rather a duplicate exist than risk any change to proven code.
Re: (Score:3)
Re: (Score:3)
This is the reason why you have comprehensive unit tests. You can refactor the original function safely in the knowledge that, if you break it, the unit tests will start failing.
You do have comprehensive unit tests?
Re:Copy and Paste. (Score:4, Insightful)
That's just for simple integer addition. When you start writing real-life code the combinations of inputs grow very quickly. You do your best, but it simply isn't practical to test for every possible thing that could cause a problem.
Re:Copy and Paste. (Score:5, Insightful)
Also agreed about too many classes. People think they make nice modular things by having short classes, but I just went through an exercise of pouring through about a dozen mind numbingly tedious files to find the single line of code that actually did something rather than just do a few pointlessly segregated checks or providing an alternative function for what '+=' already did or coercion into some datatype only to have it coerced back 'just in case' that middle layer might one day have another developer that would naturally think of it another way...
Re: (Score:3)
Envelopes stuffed into envelopes which are stuffed into envelopes, which are stuffed into manila folders which are stuffed into binders, which are stacked into cabinets, which have a security guard standing in front with orders to shoot anyone looking suspicious.
Re:Copy and Paste. (Score:5, Insightful)
For any rule you can come up with, you can probably find a valid case where breaking the rule would result in better code. Even GoTo can be useful in certain circumstances. Most of the good uses of GoTo have been codified using other key words. .C# has the continue [microsoft.com] keyword. It's basically exactly the same as using a GoTo to skip processing the current item. GoTo would have accomplished the exact same task, but people have such a dislike of GoTo that they had to create a whole other keyword that does exactly the same thing.
Re:Copy and Paste. (Score:4, Interesting)
Re: (Score:2)
The continue and break targets are clear enough in very simply code. They're much less clear when placed inside several levels of nested blocks. A goto statement has a named target you can easily search for, while the target of a break or continue statement is merely the end of the enclosing loop (or in the case of break, a switch statement). This may or may not be the same as the end of the current block.
Besides the lack of a named target, this points out another drawback of continue/break: wrapping code i
Re: (Score:3)
Documentation (Score:5, Funny)
From TFA:
my friend wired together an Eliza-like AI to his editor, and voilà, every function had a few lines of "documentation." The boss wasn't smart enough to understand that the lines meant nothing, so my friend was off the hook. His code was officially documented. I think he even got a promotion!
He should have been shot.
Re:Documentation (Score:5, Insightful)
The boss or the developer?
Yes.
Re: (Score:2)
Re:Documentation (Score:4, Interesting)
The functionality of a non private API must be documented. Requiring people to read the code in a function in order to find out what it is supposed to do is stupid.
If a programmer changes the code in a function such that its API documentation is wrong, the documentation hasn't gone stale, the programmer introduced a bug.
long methods and coupling (Score:5, Insightful)
long methods - someone thought it a good idea to limit every method to no more than 20 lines. I think this is a terrible idea, and can make code unreadable, which leads to:
coupling - it's often best to tightly couple things for ease of debugging and development. How often are you going to change the database you're using? Is it worth going through another abstraction for every database call? Too much abstraction makes code unwieldy.
I'd rather have a bunch of 200 line methods that represent logical units of work than a call stack 20 layers deep.
Re: (Score:2)
a call stack 20 layers deep.
This here is my pet peeve of most 'modern' code projects, an insane call stack. Sometimes there's good reason, but often it's simply because the project is badly duct taped together rather than carefully thought out.
Exacerbated in a lot of cases even more by having multiple over the network calls to chain several of these sorts of atrocities together. I have seen a team charged with being a sort of single middleware for a pretty straightforward sort of job self-create 4 distinct processes that each get in
Re: (Score:2)
long methods - someone thought it a good idea to limit every method to no more than 20 lines.
Show them tcp_input(). After they have a heart attack at the number of pages it takes to implement the input state machine for the TCP protocol, bury them, and get on with your life.
Re: (Score:2)
When I have run into long methods the solution usually is not a deep call stack, but instead that the method has chained together 20 10 line logical units. It would make the code more readable to have that be 20 sequential (not nested) calls to well named functions that accurately describe what they are doing. Often those logical units are different if/else blocks as well, so extracting them makes it easier to unit test all branches rather than trying to set up 200 different branch possibilities on one me
Re: (Score:3)
GOTOs in C (Score:2, Interesting)
I often use GOTO statements in C code to mimic exception catching without duplicating cleanup code. It works very well, and its easy to understand, maintain, and debug. Example:
x = do_stuff();
if (x 0) { goto cleanup; }
y = do_more stuff();
if (y 0) { goto cleanup; }
return 1;
cleanup:
fix_my_mess();
fix_it_4realz();
return 0;
Re:GOTOs in C (Score:5, Interesting)
Comp Sci professors teach "goto = bad" because the wisdom necessary to use it competently comes only with experience. It's like jazz; you have to know the rules and follow them before you can break them and not sound like a jack-ass.
Re: (Score:3, Interesting)
{
fix_my_mess();
fix_it_4realz();
}
x = do_stuff();
if (x == 0){
cleanup();
return 0;
}
y = do_more_stuff();
if (y == 0){
cleanup();
return 1;
}
return 0;
Re:GOTOs in C (Score:4, Insightful)
So far we have 3 comments with the "right" way to do it that do nothing but add complexity and loss of readability for strict adherence to dogmatism imparted by our CS professors (few of whom had real-world programming experience).
This is a straightforward problem. The suggested use of goto is a straightforward solution, and cleaner by far than the suggested alternatives. But most importantly, no one can demonstrate how it is wrong.
Re:GOTOs in C (Score:4, Insightful)
Wow. WAY too much code for what it actually needs to be. Furthermore the fix functions have now leaked scope all the way to main().
Re: (Score:3)
Dijkstra Nailed It (Score:5, Insightful)
In short, I suggest that the programmer should continue to understand what he is doing, that his growing product remains firmly within his intellectual grip. It is my sad experience that this suggestion is repulsive to the average experienced programmer, who clearly derives a major part of his professional excitement from not quite understanding what he is doing. In this streamlined age, one of our most undernourished psychological needs is the craving for Black Magic and apparently the automatic computer can satisfy this need for the professional software engineer, who is secretly enthralled by the gigantic risks he takes in his daring irresponsibility. For his frustrations I have no remedy......
--Edsger W. Dijkstra
Lessons (Score:5, Interesting)
Variable and object naming, and commenting is an art-form that takes experience to do well. Here's a few practical guidelines I've learned follow:
1. Think of newspaper headlines when commenting. Don't make somebody read the whole article to know what the article is about.
2. Comment the "odd" stuff, not the obvious stuff infer-able from function name etc.
3. Goldilocks Rule: Names both too long and too short can be bad.
4. The more frequent a name is used, the shorter it should be. Use comments at declaration to give the full name. Example of a variable that may be used often:
var dhv_id; // Department of Housing vendor ID
If it's used often, I'd rather have an abbreviation than see DeptOfHousingVendorID all over the code, making it long and "wrappy".
5. Everybody has their own preference, but you have to target the "average" developer (future unknown reader) to make code future-friendly.
Re: (Score:2)
Nice ones.
There's also a Goldilocks size for functions: functions too long are a pain to decipher, and it's easy to get lost between calls when all functions are too short. The same applies for OOP with the trade off between one Godzilla class and the Lasagna of too many classes.
Re: (Score:3, Insightful)
I've been programming for quite awhile and honestly I'm in the verbose commenting camp.
Not because I'm worried about code reviews, handing the code off to anyone else or even following some company's arbitrary rules on how things should be documented.
I use verbose comments so I don't have to remember what was done and why it was done that way. Frankly I've got too many other things that I'd rather remember.
Granted verbose comments will make my code seem pretty old school, but I have yet to hear any questio
Re:Lessons (Score:5, Funny)
One extra space per bracket (Score:3)
Just one extra (or fewer) space per bracket...'cause I know it's driven SOMEONE nuts at every shop I've worked at.
Not really about "better, more efficient" code (Score:2)
ComeFrom's (Score:2)
Breaking out of the middle of a loop (Score:2)
Since when is returning from the middle of a loop a bad thing? I've never been taught that, and it certainly hasn't been a guiding principle in any code base I've worked in.
break, don't return. Better - while(&&) (Score:2)
Combine that with another poster's 200-line methods and someone looking at the code has no easy way to know what the code returns - what it DOES . And the person looking at it my be you in two years. Also, such code -lies- about what it does. More on that in a minute.
It is better to return at the bottom of a function, partly so you can FIND the damn return statement. So an improvement over return () in the middle of the function is to break.
Even better, make the loop condition honest. Instead of this:
w
Re: (Score:2)
I think it's an extension of best practice having only one return in a function... which I kind of agree with since it works into your try catch loop. If you need more than one you probably need to split break up your method into more than one function
Re:Breaking out of the middle of a loop (Score:5, Insightful)
Re: (Score:2)
There are a lot of people out there who subscribe to the "single point of exit" theory, meaning all your code paths through a function should lead to the same return point.
I am not one of those people.
Unapologetically guilty. (Score:2)
For #6 (reinventing data structures), gimme a frickin' break - I will not pull in a 3rd party library just to implement a data structure I c
cut and paste (Score:2)
-although if/when I end up doing parameterization I have to hunt through the code and delete all the stuff that was obsoleted by the parameterization
-I'm just sayin'
All rules are not created equal (Score:2)
There are a lot of bad "rules" running around out there. There's also a lot of good ones. Some have evolved through painful experience; others are more like cargo-cult beliefs. But the bottom line is that we're all terrible judges of our own work. That's why authors need proofreaders and (frequently) editors. If you want to break something you think is a rule, for whatever reason, try checking with your cow-orkers, to see what they think about it. Yes, they may all be hide-bound idiots, but if you get hit b
#8 variable name length defines scope (Score:2)
The longer or more descriptive the variable name, the wider the scope.
can't code, afraid of disapproval (Score:5, Insightful)
It seems that many in the field these days are afraid to code something themselves for fear that someone will find fault. So, they do things "the established" way, which is generally frameworks or anything that can be called "reusable", even if this generation's "reusable" is always less reusable than last, because it keeps getting needlessly more complex to the point that nobody *can* reuse it.
Used to be programmers had a fault we called "not invented here", in that they'd insist on re-writing things that already existed, because it was easier to understand their own code than to use someone else's. These days it's reversed. For fear of criticism, they *must* use someone else's code rather than write their own. I call it "afraid to invent it here."
tools, not rules (Score:2)
I see a lot of rigidity around buzzwords and established practice, because programmers these days are given tools, and to appear smart to other programmers, they treat these tools as rules. As if knowing some rules is more important that solving problems and getting the job done. It's apparently easier to show how smart you are by regurgitating rules and criticizing people who don't follow them rigidly than it is to actually accomplish things.
Re: (Score:2)
Seriously people still use the goto statement and love it? I have never meet anyone that loved the goto statement.
GOTO http://developers.slashdot.org/comments.pl?sid=8199619&cid=50767419 [slashdot.org]
Re: (Score:3)
Seriously people still use the goto statement and love it? I have never meet anyone that loved the goto statement.
It's only loved by people who think functions should be single entry, single exit, so that you can wrap the code in asserts during testing so that you can be sure that you've got the right lock state on entry and exit. It's also great for detecting memory leaks.
If you never use locks, or never had a lock leak, or never had a memory leak, or know bugger all about assembly (the compiler is going to emit the JMP instruction, whether you like it or not, and if you don't understand assembly, you should probably
Re: (Score:2)
I really hoping you are being sarcastic because if not, you really haven't worked on any projects of real size. What you describe is really nice for an app that does addition and subtraction, but when you have connections with multiple databases, have several dozen static sockets connections going while processing messages from those sockets, your suggestion of not using objects is naive at best.
Re: (Score:2)
Of course I was being sarcastic. Pretty much obvious, don't you think ?
But still - on Embedded world you can do much without relying on dynamic allocation (and the expensive free). Just needs careful sizing and requirements analysis.
Alvie
Re: (Score:2)
I just do some Perl (Score:2)
Using Perl pretty much covers all nine and then some.
Except, perhaps, for #5 Yo-yo code. That is actually a built-in feature.