ok what are the rules
-
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 :):)
Buy a copy of Steve McConnell's Code Complete for the office. Depending on what languages you're using look up the recommended style and/or practices guides on the web. E.g., for .NET this would be MS's Design Guidelines for Class Library Developers in the MSDN library. Though I don't think this has been updated for .NET 2.
Kevin
-
Buy a copy of Steve McConnell's Code Complete for the office. Depending on what languages you're using look up the recommended style and/or practices guides on the web. E.g., for .NET this would be MS's Design Guidelines for Class Library Developers in the MSDN library. Though I don't think this has been updated for .NET 2.
Kevin
i am using c# .net with directx
-
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 :):)
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
-
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
Rama Krishna Vavilala wrote:
There is also this article by Joel: 12 Steps to Better Code
Re: No. 8 I've never worked in a quiet environment (unfortunately).
Kevin
-
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:
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.
-
Rama Krishna Vavilala wrote:
There is also this article by Joel: 12 Steps to Better Code
Re: No. 8 I've never worked in a quiet environment (unfortunately).
Kevin
You are not alone.
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
-
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.
I wish I had a door I could slam in your face.
-- Please rise for the Futurama theme song
-
I wish I had a door I could slam in your face.
-- Please rise for the Futurama theme song
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
-
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.
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
-
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.
Why? Is it a bad idea for programmers to work together? To test frequently? To simplify and consolidate existing code before adding more? To avoid unnecessarily complex structures and techniques? To strive for simple, easy-to-use interfaces? To be exposed to alternate ideas and ways of doing things?
-
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