ok what are the rules
-
BTW I like all of his points except the last one. For a moment I thought that he was reformed.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
Rama Krishna Vavilala wrote:
For a moment I thought that he was reformed.
Me too
-
The Grand Negus wrote:
They should avoid nested IFs and nested LOOPs.
Quite harsh but I agree we should avoid deep nesting (McConnell suggess no deeper than 3). But in my experience almost no-one does.
Kevin
Kevin McFarlane wrote:
Quite harsh but I agree we should avoid deep nesting (McConnell suggess no deeper than 3). But in my experience almost no-one does.
Agreed; almost no-one does. But we do, and we've found it a good idea to do so. And we've written significant programs with no nesting at all to prove the point. We believe it (1) streamlines the design, (2) increases readability, and (3) improves reliability.
-
BTW I like all of his points except the last one. For a moment I thought that he was reformed.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
Rama Krishna Vavilala wrote:
BTW I like all of his points except the last one. For a moment I thought that he was reformed.
But what's wrong with the last one? Since the project involves DirectX, why not take a peek at DarkBasic and see what they've done with it? And no one can deny that Wirth doesn't know his stuff and is worth reading - especially when such a compact example of his mature work is readily available. And since the Plain English development system is the only program I know that illustrates not only the desirability but the feasibility of eliminating nested IFs, LOOPs, and spurious widgets, why not recommend it? It's an excellent example of thinking "outside the box" that can't be found elsewhere.
-
BTW I like all of his points except the last one. For a moment I thought that he was reformed.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
It's curious that you quote Kernighan in your signature. Take a moment to review a list of his ideals for programming languages as found, say, in early writings on "C", and then ask yourself whether our Plain English system is closer to satisfying those ideals, or whether something like C# plus managed DirectX is...
-
there were few discussions about rules for programming few days ago i am working in a company which is newly started and only two programmers there and no one to guide except CP so what are the rules which you follow and think i should also follow :):)
-
there were few discussions about rules for programming few days ago i am working in a company which is newly started and only two programmers there and no one to guide except CP so what are the rules which you follow and think i should also follow :):)
Amar Chaudhary wrote:
so what are the rules which you follow and think i should also follow
Sorry, forgot one - a very important one: Abandon the "object oriented" way of thinking and write the thing, as much as possible (with the language you've chosen), as traditional procedural code. Keep your nouns (data definitions) and your verbs (operations on those nouns) separate.
-
I wish I had a door I could slam in your face.
-- Please rise for the Futurama theme song
Joergen Sigvardsson wrote:
I wish I had a door I could slam in your face.
:laugh:
-
Amar Chaudhary wrote:
what are the rules which you follow and think i should also follow
Here are a few things that have worked for us, and that you probably won't hear from anyone else: The programmers should work as a team on a single computer with dual monitors, keyboards, and mice. They should take turns leading and following. The leader gets the mouse; the other types in the appropriate code. They should test as often as possible, typically every ten lines of code (or so). They should start each day with a review of the code, looking very hard for things to delete. Less is more. No new code until something old has been removed, consolidated, or otherwise improved. They should avoid nested IFs and nested LOOPs. They should avoid the wanton use of dialogs, and minimize the number of controls on any interface. But before they begin, they should get a copy of DarkBasic and play with it as an illustration of an alternate use of the DirectX libraries. Then they should read Wirth's Oberon book as an example of alternate interfaces and efficiency in design and implementation. Finally, they should get the Plain English development system and work their way through it to further broaden their thinking.
The Grand Negus wrote:
programmers should work as a team on a single computer
Ah, pair programming. Sometimes two pairs of eyes are better than one :)
-
Amar Chaudhary wrote:
so what are the rules which you follow and think i should also follow
Sorry, forgot one - a very important one: Abandon the "object oriented" way of thinking and write the thing, as much as possible (with the language you've chosen), as traditional procedural code. Keep your nouns (data definitions) and your verbs (operations on those nouns) separate.
The Grand Negus wrote:
Abandon the "object oriented" way of thinking and write the thing, as much as possible (with the language you've chosen), as traditional procedural code.
Nope, I don't think so.
If you try to write that in English, I might be able to understand more than a fraction of it. - Guffa
-
As Kevin stated Code Complete is a must read. For C# and .NET one should read the Framework Design Guidelines book by Brad Abrams and Krystzof Cwalina. Design Patterns book is also a must read. Steve McConnell's code complete book has a list of books that developers should read depending on their levels. I think that is a great list (except few of the books are not in print). There is also this article by Joel: 12 Steps to Better Code [^]
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
this is my second job (3 month passed) my first job (fox pro for accounting solution or can say immediate reports no structure for code or any thing else no training instead i had to go to client location from the first day i work from there only no previous experience of fox pro they give me one program which was used to calculate interest and they give me source code yes pc given to me was better so i had one day to learn fox pro basics and i did that of course not whole but the basic things required for me to work there thanks to msdn and internet connection ) before joining my first job i did a .net course (3 months). My .net teacher refer me to my current job i joined this job (my salary was hiked almost 5 times and i got a team (one more student of sir) to work with again we got no training however it took a bit longer to understand few needed concepts of directx and webcam yes articles from code project were the only source of info i could had that time (no books of directx with c# available that time in EE edition and i had not enough money to buy the costlier books so i will say thanks a lot CP now the questions of Joel 1. Do you use source control? i did not know this thing before so i will implement it ASAP 2. Can you make a build in one step? Yes as we are two we work together 3. Do you make daily builds? no i didn't 4. Do you have a bug database? i will make it ASAP (today itself) 5. Do you fix bugs before writing new code? well most i fix them after writing the code cause if i am implementing some thing new i don't know that it will work or not after my basic idea starts to work then i take some free time and think throughly to find bugs before implementing any further 6. Do you have an up-to-date schedule? yes we complete one thing then take target for the next one and accomplishes it on time however i have to give many sleepless nights 7. Do you have a spec? yes i build the outer line on the day one but don't have any fine specs 8. Do programmers have quiet working conditions? no not at office and we have to complete our first project before 30th so i am working from my home 9. Do you use the best tools money can buy? no this is the part we lag most we have two computers at office one we work upon is p4 1.2 ghz with 256 mb ram (i wonders how .Net is running on it with XP and directx SDK loaded) second computer is worse we cant use it for programming / testing it is only used for browsing (p3 .5 ghz 256 mb ram) we don`t have those dual monitors or lcd e
-
there were few discussions about rules for programming few days ago i am working in a company which is newly started and only two programmers there and no one to guide except CP so what are the rules which you follow and think i should also follow :):)
-
there were few discussions about rules for programming few days ago i am working in a company which is newly started and only two programmers there and no one to guide except CP so what are the rules which you follow and think i should also follow :):)
Amar Chaudhary wrote:
so what are the rules which you follow and think i should also follow
- Programmers make stuff up. By definition. And no matter how alluring and elegant, the continued existence of any given program is due far more to whim and entropy than to any concrete requirement. So don’t get too hung up on others’ flights of fancy – learn to read intentions and recognize designs.
- If you don’t know why it works, it might as well not work at all.
- Don't write code that you cannot read. Avoid any languages, practices, or "clever tricks" that lead down this path.
---- I just want you to be happy; That's my only little wish...
-
John Cardinal wrote:
The only rule that matters to a startup is make money.
Yes, that is an important rule. Once money making is established in the startup, define and optimize the business process as time goes on.
If you try to write that in English, I might be able to understand more than a fraction of it. - Guffa
-
Kevin McFarlane wrote:
Quite harsh but I agree we should avoid deep nesting (McConnell suggess no deeper than 3). But in my experience almost no-one does.
Agreed; almost no-one does. But we do, and we've found it a good idea to do so. And we've written significant programs with no nesting at all to prove the point. We believe it (1) streamlines the design, (2) increases readability, and (3) improves reliability.
The Grand Negus wrote:
We believe it (1) streamlines the design, (2) increases readability, and (3) improves reliability.
In my experience, it goes a long way towards #2 - #1 and #3 follow naturally from there. Yet, i'll still see programmers who will take a perfectly good design, and implement it in a way that is near impossible to read, improve, or maintain. Long, deeply-nested blocks of code, duplicated blocks of code, poor naming conventions... it's like picking up a novel, only to find the author has written exactly one very, very long sentence per page.
---- I just want you to be happy; That's my only little wish...
-
yes we will soon sell our product (and best part is that purchasers are waiting for that because of sirs link in the market) :)
it is good to be important but it is more important to be good
-
The Grand Negus wrote:
Abandon the "object oriented" way of thinking and write the thing, as much as possible (with the language you've chosen), as traditional procedural code.
Nope, I don't think so.
If you try to write that in English, I might be able to understand more than a fraction of it. - Guffa
PaulC1972 wrote:
The Grand Negus wrote: Abandon the "object oriented" way of thinking and write the thing, as much as possible (with the language you've chosen), as traditional procedural code. Nope, I don't think so.
Just trying to save these folks a bit of time and trouble. The suggestion saves time because (1) there won't be endless arguments about how to squeeze the problem into an object hierarchy, and (2) there won't be endless debates about how to "simulate" design requirements that C# doesn't support (like multiple inheritance). The suggestion saves trouble because the resulting code will be more orthogonal and thus easier to understand, maintain, and especially extend.
-
Amar Chaudhary wrote:
so what are the rules which you follow and think i should also follow
- Programmers make stuff up. By definition. And no matter how alluring and elegant, the continued existence of any given program is due far more to whim and entropy than to any concrete requirement. So don’t get too hung up on others’ flights of fancy – learn to read intentions and recognize designs.
- If you don’t know why it works, it might as well not work at all.
- Don't write code that you cannot read. Avoid any languages, practices, or "clever tricks" that lead down this path.
---- I just want you to be happy; That's my only little wish...
Shog9 wrote:
"clever tricks"
i do use some times but comment them to remove later and as soon as i get any solution i implement that :)
it is good to be important but it is more important to be good
-
Amar Chaudhary wrote:
what are the rules which you follow and think i should also follow
Here are a few things that have worked for us, and that you probably won't hear from anyone else: The programmers should work as a team on a single computer with dual monitors, keyboards, and mice. They should take turns leading and following. The leader gets the mouse; the other types in the appropriate code. They should test as often as possible, typically every ten lines of code (or so). They should start each day with a review of the code, looking very hard for things to delete. Less is more. No new code until something old has been removed, consolidated, or otherwise improved. They should avoid nested IFs and nested LOOPs. They should avoid the wanton use of dialogs, and minimize the number of controls on any interface. But before they begin, they should get a copy of DarkBasic and play with it as an illustration of an alternate use of the DirectX libraries. Then they should read Wirth's Oberon book as an example of alternate interfaces and efficiency in design and implementation. Finally, they should get the Plain English development system and work their way through it to further broaden their thinking.
The Grand Negus wrote:
They should avoid nested IFs and nested LOOPs.
i noted it down :)
it is good to be important but it is more important to be good
-
yes we will soon sell our product (and best part is that purchasers are waiting for that because of sirs link in the market) :)
it is good to be important but it is more important to be good
Amar Chaudhary wrote:
we will soon sell our product (and best part is that purchasers are waiting for that because of sirs link in the market)
Good luck to you guys. Hope your work starts to pay itself off :-D
I'd like to help but I don't feel like Googling it for you.
-
PaulC1972 wrote:
The Grand Negus wrote: Abandon the "object oriented" way of thinking and write the thing, as much as possible (with the language you've chosen), as traditional procedural code. Nope, I don't think so.
Just trying to save these folks a bit of time and trouble. The suggestion saves time because (1) there won't be endless arguments about how to squeeze the problem into an object hierarchy, and (2) there won't be endless debates about how to "simulate" design requirements that C# doesn't support (like multiple inheritance). The suggestion saves trouble because the resulting code will be more orthogonal and thus easier to understand, maintain, and especially extend.
The Grand Negus wrote:
resulting code will be more orthogonal and thus easier to understand, maintain, and especially extend.
But code reuse isn't as good as in object oriented programming. Get with the times, traditional procedural programming is old school and part of the past. I haven't done procedural coding in about 15 years :->
I'd like to help but I don't feel like Googling it for you.