The purpose of this thread is to know:
1- What makes one C program more powerful than other C program
2- What is the things that you avoid when writing your C program in order to conclude with robustness and perfect program – the type of variable ..etc
3- What is the optimal format of C program
4- What is your first object –as a good C programmer—when you start writing your program
5- Do you concern of the time required to execute the C program
1. A faster algorithm that actually works. Or maybe a program that does more; works harder.
2. Make sure your program never experiences undefined behavior.
3. Code that looks clean.
4. I normally study the problem and write down what I expect my program to do.
5. What? ...well... if I understand your question, it should finish executing before I'm old.
I suppose with item 5, it really depends on what the program is intended for. If you are talking abt a time-critical software, then yes... otherwise, it is not too impt really.
Normally what I do is to get the functional aspect to work first, then I will proceed to optimize the code.
Just remember:
Every program contains at least one bug.
Every program can be reduced by one line.
Therefore, every program can be re-written as one line of code that doesn't work.
If you understand what you're doing, you're not learning anything.
You seem to be under the impression that software development can be turned into a set of rules that a machine can follow. That's just not the case. The human element is essential, and those attributes (creativity, judgement, etc..) can't be simulated with rules or guidelines, and they're what give birth to truly superior software.
>1- What makes one C program more powerful than other C program
Your question is too vague.
>2- What is the things that you avoid when writing your C
>program in order to conclude with robustness and perfect program
Robustness comes from an attention to detail, not so much specific things that one avoids.
>3- What is the optimal format of C program
There isn't any. Optimal for any program is unique to that program, so you can't have any hard rules about what the optimal format is for every program.
>4- What is your first object –as a good C programmer—when you start writing your program
A strong foundation (ie. a good design).
>5- Do you concern of the time required to execute the C program
Yes, but only when it matters. I generally won't try to heavily optimize parts of my program that are I/O bound because the effect won't be noticeable by end-users.
My best code is written with the delete key.
Optimal is in the eye of the beholder. Consider the following different people with different views on the word "optimal":
Manager: the software is built, tested and packaged in 3 months.
Embedded systems engineer: less than 5 kilobytes of binary code. Size is everything.
Game developer: who cares about the CPU anymore. As long as it doesn't blow the graphics card.
Assembly coder: replace trival tasks with complex bitwise operations. Speed is an art.
Security administrator: no memory leaks, no disk writes, no page files. All data must be encrypted.
Computer scientist: no bug testing for me, I've proved this code works. Deal with it.
Code:#include <stdio.h> void J(char*a){int f,i=0,c='1';for(;a[i]!='0';++i)if(i==81){ puts(a);return;}for(;c<='9';++c){for(f=0;f<9;++f)if(a[i-i%27+i%9 /3*3+f/3*9+f%3]==c||a[i%9+f*9]==c||a[i-i%9+f]==c)goto e;a[i]=c;J(a);a[i] ='0';e:;}}int main(int c,char**v){int t=0;if(c>1){for(;v[1][ t];++t);if(t==81){J(v[1]);return 0;}}puts("sudoku [0-9]{81}");return 1;}
Here's my 2 cents worth......
You can't boil it all down like that.
If an emergency rises, and I need to crank out something to fill a need and have an hour to do it, the program that I write that fills the need IS the optimal program.
It might not run as quickly or efficiently as one that I would spend days writing, it might not be as extensible as one that is more correctly designed. It could be a total hack. But given those initial requirements, it would be THE optimal program.
Barring that, I tend towards good design, efficient coding, and the ability to be extensible. I can't tell you how many times over the years I've written something and within a year or two, so many more features have been added. Thinking extensibility early on saves me time later.
And even after 25 years in this game, I'm still learning -- that's for damned sure
Mr. Blonde: You ever listen to K-Billy's "Super Sounds of the Seventies" weekend? It's my personal favorite.
"That's Bob, the programmer. He can see ways to make computers work. But can he see what why kids love Cinnamon Toast Crunch?" "It's got guidelines?" "No, silly - cinnamon swirls in every bite! Part of a balanced breakfast - Cinnamon Toast Crunch! The taste you can see!"
(They owe me for that...) Seriously, there isn't a clear cut solution. Adequate planning will save many headaches, but each project is different. So... here goes:
1) Depends. Sometimes one program will be faster than its competitor, but the competitor will have a easier learning curve. Which is superior? Sometimes, it depends not on the program, but on the needs of those using the program.
2) Avoid stupid stuff. Breaking portability where you needn't, etc. Not using a tool easily available.
3) If you mean code layout, pick a brace style and indentation and stick to it. Countless times has this forum been defaced with code that has no indentation what-so-ever. Save yourself headaches when the code grows: Indent. (See The One True Brace Style for starters... though I don't use (exactly) it myself.)
4) I really ought to plan more.
5) I don't concern myself while coding. A working program that goes slow is better than a broken one that segfaults in 1/2 sec. Worry about optimizations when you know where they're needed. (And when your program gives you an ETA of 200+ yrs...)
long time; /* know C? */
Unprecedented performance: Nothing ever ran this slow before.
Any sufficiently advanced bug is indistinguishable from a feature.
Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
The best way to accelerate an IBM is at 9.8 m/s/s.
recursion (re - cur' - zhun) n. 1. (see recursion)
