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 :):)
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.[^]
-
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.
-
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
-
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
-
The Grand Negus wrote:
On a more philosophical note
Come on. Have you heard of a guy named Descartes? (I think therefore I am). He did an excellent work thinking about how to think. He developed what is called today the top-down approach. This way of thinking is particularly useful, and has been applied successfully in many disciplines, and led to fruitful solutions. For software it was very useful too. That's the underlying concept for procedural computing. But software remains a discipline with its own particularities. And as projects became larger and larger, it appeared this approach had some drawbacks (especially for evolving the systems). (See Meyer on this). So OOP brings in a very nice concept, I mean bottom-up approach. Top-down remains a must for designing a system, but bottom-up provides extremely valuable features for implementing software systems. (procedural remains useful for small and low level code, but the days of 64k central memory are over)
An interface, file manager, hexadecimal dumper, text editor, native-code generating compiler, and a wysiwyg page layout facility combined into a single program is not a trivial system. And yet we accomplished it, simply, conveniently, and with remarkably efficiency - both in development and when it runs - without objects. We've created other equally complex systems likewise. The point being that large projects can be managed without resorting to the unnatural forms demanded by the object-oriented approach.
-
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.[^]
Jeremy Falcon wrote:
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?
It depends, as you should know. If he buys it to use as is, we get $100. But where's the hypocrisy in that? We've never hidden the fact that our product is for sale. And if he decides to develop on top of it, he'll get a copy to work with for free and then he'll sell his product - in that case, he'll benefit financially as well. Finally, if he becomes a full-fledged Omsosian living and working together with us, drinking milk from the same cows and eating corn from the same fields, I really don't think the question applies - except that, again, I see no hypocrisy there.
-
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
The Grand Negus wrote:
Polymorphism built into the current Plain English compiler.
And polymorphism is one of the tenants of OO as well. Indeed, while it is quite useful in a purely procedural language, it is nearly essential in an OO one, as without it you quickly end up with:
The Grand Negus wrote:
"number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)"
string var = numberThere's no reason why the assignment operator shouldn't act differently based on context.---- I just want you to be happy; That's my only little wish...
-
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 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.
How about this argument. We wrote an exceptionally efficient native-code-generating compiler/linker with interface, file manager, dumper, text editor, and wysiwyg page editor using exclusively procedural code and not once during the development did the project suffer from disorganization, unreliability, or unnatural expression and not once during the development were we ever even tempted to think in an object-oriented paradigm. If that doesn't do it for you, I don't think a handful of posts here will help. When I first started teaching database design many years ago, I wrote into my materials an appendix explaining why the hierarchical and network approaches to database management were less desirable. I soon found, however, that once students mastered the simple and obvious relational approach taught in the course, the appendix ceased to be of interest; so I delete it. I think the same thing applies here. If you have a particular example where you think object-oriented thinking works better than a procedural approach, however, I'll be happy to dissect it.
-
An interface, file manager, hexadecimal dumper, text editor, native-code generating compiler, and a wysiwyg page layout facility combined into a single program is not a trivial system. And yet we accomplished it, simply, conveniently, and with remarkably efficiency - both in development and when it runs - without objects. We've created other equally complex systems likewise. The point being that large projects can be managed without resorting to the unnatural forms demanded by the object-oriented approach.
Any approach can be destructive if imposed on a problem to which it doesn’t suit. If you try to see objects where none usefully exist your efforts will end in tears; conversely, if you refuse to see objects when they occur in the problem naturally and intuitively you’ll also have problems. OO isn’t the be all and end all but by the same token militant anti-OO doesn’t seem to me to be the way to go either. A perfect example is C++’s STL; it many ways it isn’t OO: the algorithms are separated from the containers for example. That said the containers themselves are objects, they just don’t include the algorithms.
Steve
-
The Grand Negus wrote:
Polymorphism built into the current Plain English compiler.
And polymorphism is one of the tenants of OO as well. Indeed, while it is quite useful in a purely procedural language, it is nearly essential in an OO one, as without it you quickly end up with:
The Grand Negus wrote:
"number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)"
string var = numberThere's no reason why the assignment operator shouldn't act differently based on context.---- I just want you to be happy; That's my only little wish...
Shog9 wrote:
The Grand Negus wrote: Polymorphism built into the current Plain English compiler. And polymorphism is one of the tenants of OO as well. Indeed, while it is quite useful in a purely procedural language, it is nearly essential in an OO one, as without it you quickly end up with: The Grand Negus wrote: "number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)" string var = number There's no reason why the assignment operator shouldn't act differently based on context.
Yes, yes. But you've hidden the problem, not solved it. To do the conversion, does the assignment operator call "number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)"? In other words, where is the conversion function defined? (And please don't say "under the assignment operator object" because there are clearly two different operations here: assignment of a value to a compatible container is not the same thing as the conversion of a value from one representation to another.)