ok what are the rules
-
Consider reading this http://www.netobjectives.com/download/Code%20Qualities%20and%20Practices.pdf[^]
Hey, Richard, this looks quite good from a casual glance. I'll print it out and read it tomorrow. I've already read their Design Patterns book.
Kevin
-
Hey, Richard, this looks quite good from a casual glance. I'll print it out and read it tomorrow. I've already read their Design Patterns book.
Kevin
If you require details of related matters then post your needs. Also, note that some time ago I posted details of Microsoft's Architecture Journal. Well, Journal 9 has just been issued. For you and others who might want a hard copy delivered to your home/work address or wishing to download PDF's of all issues of this journal, point your browser at www.architecturejournal.net[^]
-
Consider reading this http://www.netobjectives.com/download/Code%20Qualities%20and%20Practices.pdf[^]
Interesting article - but I have real issues with the first two points.
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
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 :):)
- Get a grip on the logic of what you are trying to accomplish before you start. ie. Understand exactly what it is you are trying to accomplish
- Use the right tool for the job. Ignore anyone who says you *must* use such-and-such a tool or technique.
- Learn the concepts of programming. Memory management, design patterns, organising your code into the correct peices (objects, procedures, files, namespaces)
- Understand the concepts of the technology you are using. Object oriented, web based, crazy anonymous functions. Learn the tools.
- Write pretty code. Forcing yourself to write good looking code will force you to take a look at the structure, the comments, the way it's broken up, and as a consequence it will be easier for someone else to read and check
- Write comments in code. Relevant comments. Lots of useful, relevant comments.
- Learn to test and debug
- Learn how to rip chunks out of your code and replace it as the specs change. And they will change. Never, ever believe that there is such a thing as a final spec sheet.
- Keep learning.
- Be good to your Mother.
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
- Get a grip on the logic of what you are trying to accomplish before you start. ie. Understand exactly what it is you are trying to accomplish
- Use the right tool for the job. Ignore anyone who says you *must* use such-and-such a tool or technique.
- Learn the concepts of programming. Memory management, design patterns, organising your code into the correct peices (objects, procedures, files, namespaces)
- Understand the concepts of the technology you are using. Object oriented, web based, crazy anonymous functions. Learn the tools.
- Write pretty code. Forcing yourself to write good looking code will force you to take a look at the structure, the comments, the way it's broken up, and as a consequence it will be easier for someone else to read and check
- Write comments in code. Relevant comments. Lots of useful, relevant comments.
- Learn to test and debug
- Learn how to rip chunks out of your code and replace it as the specs change. And they will change. Never, ever believe that there is such a thing as a final spec sheet.
- Keep learning.
- Be good to your Mother.
cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
Get a grip on the logic of what you are trying to accomplish before you start. ie. Understand exactly what it is you are trying to accomplish
This is a fun when the client is vague about their requirements.
I'd like to help but I don't feel like Googling it for you.
-
Where is the hypocrisy in recommending the best we have to offer, on-topic, to someone who is looking for good ideas regarding programming? We wrote the thing for this very purpose; why shouldn't we offer it?
The Grand Negus wrote:
why shouldn't we offer it?
Because it's free advertising in the lounge, or did you forget already? Who stands to get paid if he actually does decide to use PEP?
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
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
Ok, here's the general lowdown...
- Code Complete is a great book, this is no exaggeration.
- OOP is nice, but it's not always the answer. Don't be afraid to not use it (they have OOP zealots, that don't know a thing about what they preach), and don't be afraid to use it either (they have procedural zealots, that don't know a thing about what they preach either).
- PEP is a joke. He took a couple of nice ideas, screwed them up badly, and made a cult out of it.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
Chris Maunder wrote:
Get a grip on the logic of what you are trying to accomplish before you start. ie. Understand exactly what it is you are trying to accomplish
This is a fun when the client is vague about their requirements.
I'd like to help but I don't feel like Googling it for you.
i coded sitting on the client side and have experience of that there i used to make report out of reports which there existing software cannot produce for one report the back office head sit beside me and give me the details of what is to be done i asked for the complete details for what is to be accomplished he told me to do that part first so i did that took me two days (merging three different reports , taking rates from two different exchanges keeping the record of rates etc) then i approached him with that report for further instructions he see my report and one (main) of the three reports i have merged and compared them the figures were exactly same he said it OK then i asked that why he asked me to calculate that figure which is already in the same report he just blushed after that i take extra care for what is required :):)
it is good to be important but it is more important to be good
-
Amar Chaudhary wrote:
so what are the rules which you follow and think i should also follow
Ok, here's the general lowdown...
- Code Complete is a great book, this is no exaggeration.
- OOP is nice, but it's not always the answer. Don't be afraid to not use it (they have OOP zealots, that don't know a thing about what they preach), and don't be afraid to use it either (they have procedural zealots, that don't know a thing about what they preach either).
- PEP is a joke. He took a couple of nice ideas, screwed them up badly, and made a cult out of it.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
PEP is a joke.
I thought that when the Osmosian guys posted those articles some months ago. Couldn't make any sense of the coding and it looked like something I would have gotten agitated over.
I'd like to help but I don't feel like Googling it for you.
-
Jeremy Falcon wrote:
PEP is a joke.
I thought that when the Osmosian guys posted those articles some months ago. Couldn't make any sense of the coding and it looked like something I would have gotten agitated over.
I'd like to help but I don't feel like Googling it for you.
PaulC1972 wrote:
I thought that when the Osmosian guys posted those articles some months ago. Couldn't make any sense of the coding and it looked like something I would have gotten agitated over.
Yeah, they keep on saying PEP is more natural and you can type more code despite it being verbose because it flows so to speak. Personally, I don't think they spent enough time coding in another language that's not verbose to get that same flow. And having to use the shift key is not a show stopper for me. :rolleyes: Really though, if syntax was the only issue in debate (which it's not). I still wouldn't be crazy about it.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
Amar Chaudhary wrote:
so what are the rules which you follow and think i should also follow
Ok, here's the general lowdown...
- Code Complete is a great book, this is no exaggeration.
- OOP is nice, but it's not always the answer. Don't be afraid to not use it (they have OOP zealots, that don't know a thing about what they preach), and don't be afraid to use it either (they have procedural zealots, that don't know a thing about what they preach either).
- PEP is a joke. He took a couple of nice ideas, screwed them up badly, and made a cult out of it.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
so you have decided and firm to throw him out bravo!!!
it is good to be important but it is more important to be good
-
i coded sitting on the client side and have experience of that there i used to make report out of reports which there existing software cannot produce for one report the back office head sit beside me and give me the details of what is to be done i asked for the complete details for what is to be accomplished he told me to do that part first so i did that took me two days (merging three different reports , taking rates from two different exchanges keeping the record of rates etc) then i approached him with that report for further instructions he see my report and one (main) of the three reports i have merged and compared them the figures were exactly same he said it OK then i asked that why he asked me to calculate that figure which is already in the same report he just blushed after that i take extra care for what is required :):)
it is good to be important but it is more important to be good
Amar Chaudhary wrote:
after that i take extra care for what is required
Yep. I make it a requirement for the client to specify and make them sign it off. When they come back crying that it doesn't meet their requirement, I show them what I coded and what they signed for.
I'd like to help but I don't feel like Googling it for you.
-
PaulC1972 wrote:
I thought that when the Osmosian guys posted those articles some months ago. Couldn't make any sense of the coding and it looked like something I would have gotten agitated over.
Yeah, they keep on saying PEP is more natural and you can type more code despite it being verbose because it flows so to speak. Personally, I don't think they spent enough time coding in another language that's not verbose to get that same flow. And having to use the shift key is not a show stopper for me. :rolleyes: Really though, if syntax was the only issue in debate (which it's not). I still wouldn't be crazy about it.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
they keep on saying PEP is more natural
Yeah, a natural headache :->
I'd like to help but I don't feel like Googling it for you.
-
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.
I challenge you to flex your brain power and show all of us real (not abstract) reasons as to why you think this is the case. And I even double challenge you to do without talking about PEP. Keep in mind. C is my favorite language, and I believe procedural code can be very organized. But, I also believe OOP has many merits and don't hesitate to use it if the project calls for it. So, you have your challenge. Should you take it or leave us up to you, but since you act like an expert in this field I'd wager this would be like falling off a log. Remember, abstract ideas don't count, those are too easily manipulated to serve an agenda.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
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.
I challenge you to flex your brain power and show all of us real (not abstract) reasons as to why you think this is the case. And I even double challenge you to do without talking about PEP. Keep in mind. C is my favorite language, and I believe procedural code can be very organized. But, I also believe OOP has many merits and don't hesitate to use it if the project calls for it. So, you have your challenge. Should you take it or leave us up to you, but since you act like an expert in this field I'd wager this would be like falling off a log. Remember, abstract ideas don't count, those are too easily manipulated to serve an agenda.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
I even double challenge you to do without talking about PEP
:omg: I don't think that'll happen :laugh:
If you try to write that in English, I might be able to understand more than a fraction of it. - Guffa
-
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 :):)
- Consider a design by contract approach to writing methods/functions. 2) Limit side-effects, i.e. limit mutability as much as possible.
-
Chris Maunder wrote:
Get a grip on the logic of what you are trying to accomplish before you start. ie. Understand exactly what it is you are trying to accomplish
This is a fun when the client is vague about their requirements.
I'd like to help but I don't feel like Googling it for you.
Client vagueness has the capability that can easily turn what could be a successful software project into a disaster. Two excellent books entitled "Systems Analysis and Design Methods - by Whitten" and "Software Engineering by Ian Sommerville". Both these books are well worth their money.
-
Client vagueness has the capability that can easily turn what could be a successful software project into a disaster. Two excellent books entitled "Systems Analysis and Design Methods - by Whitten" and "Software Engineering by Ian Sommerville". Both these books are well worth their money.
Richard A. Abbott wrote:
Client vagueness has the capability that can easily turn what could be a successful software project into a disaster.
That has happened a few times and luckily have recuperated from disaster. Thanks for referring the books, will add them to the growing list of books to buy :-D
If you try to write that in English, I might be able to understand more than a fraction of it. - Guffa
-
Interesting article - but I have real issues with the first two points.
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
The Grand Negus wrote:
On a more philosophical note, we all know that cookies don't bake themselves, nor do ovens bake cookies without assistance (as the object model would lead us to believe). Someone bakes cookies in an oven. But the object approach - in great part due to the philosophical orientation of its creator - tries to ignore the existence of the active agent who is necessarily "outside" the system. If you get my drift...
As you note, i don't give my oven a list of instructions. The processor for cookies is a human, but this can be implied, and the recipe i write out might well have a bigger focus on nouns (ingredients) than verbs (actions performed on them). In fact, recipes traditionally are written with a very few key verbs, interpreted by context:
Mix: 1/2 cup milk, 3 egg yolks (beaten) 1/4 cup brown sugar Fold in: 3 egg whites (whipped to soft peaks)
Behind this procedural list of instructions, the mechanics of separating eggs, beating the yolks, whipping the whites, the distinction between mixing and folding... is hidden. The differences between measuring milk and brown sugar are assumed to be known by the processor. "measure 1/4 cup brown sugar using brown sugar measuring method" is unnecessary, as the processor knows to use the method appropriate for each ingredient. Polymorphism in action. Correct me if i'm wrong, but it seems that a big part of your argument against OO has to do with the syntax. While i'd agree that there is room for improvement in the syntax used for OO in C-derived languages, i don't find the English sentence structure a particularly appealing substitute. Perhaps this is just my personal taste, but it generally takes me twice as long to write an English description of an algorithm than it does to codify the algorithm in my language of choice (of course, my notes are nominally in English, but as a series of diagrams and brief annotations intended to jog my memory, wholly unsuitable for communicating my ideas with anyone).
---- I just want you to be happy; That's my only little wish...
Shog9 wrote:
As you note, i don't give my oven a list of instructions. The processor for cookies is a human, but this can be implied, and the recipe i write out might well have a bigger focus on nouns (ingredients) than verbs (actions performed on them). In fact, recipes traditionally are written with a very few key verbs, interpreted by context: Mix: 1/2 cup milk, 3 egg yolks (beaten) 1/4 cup brown sugar Fold in: 3 egg whites (whipped to soft peaks) Behind this procedural list of instructions, the mechanics of separating eggs, beating the yolks, whipping the whites, the distinction between mixing and folding... is hidden. The differences between measuring milk and brown sugar are assumed to be known by the processor. "measure 1/4 cup brown sugar using brown sugar measuring method" is unnecessary, as the processor knows to use the method appropriate for each ingredient. Polymorphism in action.
I'm not exactly sure of your point here. "Mix 1/2 cup milk, 3 egg yolks (beaten), 1/4 cup brown sugar. Fold in 3 egg whites (whipped to soft peaks)." is valid Plain English code, as it stands. And in Plain English one doesn't have to say "measure 1/4 cup brown sugar using brown sugar measuring method" but simply "measure 1/4 cup brown sugar" because that sentence will dispatch to the routine defined with the header "To measure some brown sugar" or, if that doesn't exist, "To measure some sugar", or if that doesn't exist, "To measure some crystals", etc, while a similar dispatching of liquid measures will also take place. Polymorphism built into the current Plain English compiler.
Shog9 wrote:
Correct me if i'm wrong, but it seems that a big part of your argument against OO has to do with the syntax.
Half right. The syntax, of course, is unnatural and strained. But my first objection was stated in the previous post - verbs don't belong under nouns. If the cookie and oven and bake example didn't make this clear, let's try a more technical one. In Plain English there's a routine to "Convert a number to a string". In objectland, is this "number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)"? Who knows? More importantly, who cares since the obvious answer was already - and naturally - arrived at in Plain English.
Shog9 wrote:
i don't find the English sentence structure a particularly appealing substitu