ok what are the rules
-
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.
-
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.
i will say that i prefer the mix of both (because of my limited knowledge i am not familiar with all the concepts of oops ) i use objects for the ease of code implementation when it is possible to make an object i make it i cant completely avoid it cause it is almost not possible for me to write with out objects ( cause objects makes things simpler for me to implement and if i think it throughly there are less chances of any bugs ) :)
it is good to be important but it is more important to be good
-
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 :):)
You should develop good coding habits not follow rules :D
Todd Smith
-
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.
PaulC1972 wrote:
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.
Or the whole object-oriented approach was a wrong turn and the sooner we get back on the right road, the better. The object approach to programming is very much like the hierarchical (and, with multiple inheritance, the network) approaches to database managent. Both the hierarchical and the network approaches gained significant popularity and support from major players (like IBM) at one time - and both were made more or less obsolete by the relational approach which was simpler and more orthogonal. We suspect the same thing will happen here. Storing data in tables isn't "old school" or "new school", it's just a good idea for many applications. Likewise, procedural programming isn't "old school" or "new school", it simply works. And as for procedural programs being worse for "code reuse" - which is overrated anyway - that simply isn't true.
-
You should develop good coding habits not follow rules :D
Todd Smith
yes i want that too cause i never have any training i don't have them structured but which i follow are 1) commenting 2) rigid nomenclature 3) spending time on CP :) 4) divide the things for ease 5) thinking before and after coding any other you want to share :):)
it is good to be important but it is more important to be good
-
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.
IMHO, if your team is determined to argue, they'll find something to argue about. Orthogonality should be a goal in and of itself - whether the code is orthogonal or procedural.
---- I just want you to be happy; That's my only little wish...
-
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.
I did not think I'd still read something like this today. Back to the 80s. :)
-
yes i want that too cause i never have any training i don't have them structured but which i follow are 1) commenting 2) rigid nomenclature 3) spending time on CP :) 4) divide the things for ease 5) thinking before and after coding any other you want to share :):)
it is good to be important but it is more important to be good
I would say a consistent coding style is a good one. I'm currently working on a project that uses both 3 and 4 space tabs and I want to commit a crime everytime I jump from style to style. An overall style guide is good if the code base will eventually be used by others. Think "Verbose" It would be interesting to come up with a list of coding practices and have them prioritized based on importance. I imagine the prioity will be different for different kinds of projects.
Todd Smith
-
PaulC1972 wrote:
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.
Or the whole object-oriented approach was a wrong turn and the sooner we get back on the right road, the better. The object approach to programming is very much like the hierarchical (and, with multiple inheritance, the network) approaches to database managent. Both the hierarchical and the network approaches gained significant popularity and support from major players (like IBM) at one time - and both were made more or less obsolete by the relational approach which was simpler and more orthogonal. We suspect the same thing will happen here. Storing data in tables isn't "old school" or "new school", it's just a good idea for many applications. Likewise, procedural programming isn't "old school" or "new school", it simply works. And as for procedural programs being worse for "code reuse" - which is overrated anyway - that simply isn't true.
Code reuse is not the sole advantage. Should we really get back to this kinds of discussions? (A vast and abundant litterature is available) Just out of curiosity, what is your favorite/working programming language? The debate about the databases is a different one. Using a relational database, has some advantages even though that requires a relational<->OO layer. But in no way this invalidates the advantages of using an OO language.
-
I did not think I'd still read something like this today. Back to the 80s. :)
Pierre Leclercq wrote:
I did not think I'd still read something like this today.
I didn't think I'd have to argue about OOP today :->
I'd like to help but I don't feel like Googling it for you.
-
PaulC1972 wrote:
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.
Or the whole object-oriented approach was a wrong turn and the sooner we get back on the right road, the better. The object approach to programming is very much like the hierarchical (and, with multiple inheritance, the network) approaches to database managent. Both the hierarchical and the network approaches gained significant popularity and support from major players (like IBM) at one time - and both were made more or less obsolete by the relational approach which was simpler and more orthogonal. We suspect the same thing will happen here. Storing data in tables isn't "old school" or "new school", it's just a good idea for many applications. Likewise, procedural programming isn't "old school" or "new school", it simply works. And as for procedural programs being worse for "code reuse" - which is overrated anyway - that simply isn't true.
ok i'll bite ... do you really consider data hiding, loose coupling, re-use through sane inheritance and function overloading to be bad things? i would have to ask what level of software systems you have worked on but these concepts have been shown to work in the real world for large mc systems ... yet you throw it all away based upon some notion that procedural code is the one true way? classes are procedural code in their member functions ... it's just that the whole entity is wrapped in a "safe" package for consumption really when you say such things as "oo programming is a mistake" you really dont give yourself any credibility here where your audience is largely made up from some of the best programmers in the world sheesh
-
Code reuse is not the sole advantage. Should we really get back to this kinds of discussions? (A vast and abundant litterature is available) Just out of curiosity, what is your favorite/working programming language? The debate about the databases is a different one. Using a relational database, has some advantages even though that requires a relational<->OO layer. But in no way this invalidates the advantages of using an OO language.
Pierre Leclercq wrote:
Should we really get back to this kinds of discussions?
No, because I don't want to :zzz: right now :laugh:
I'd like to help but I don't feel like Googling it for you.
-
ok i'll bite ... do you really consider data hiding, loose coupling, re-use through sane inheritance and function overloading to be bad things? i would have to ask what level of software systems you have worked on but these concepts have been shown to work in the real world for large mc systems ... yet you throw it all away based upon some notion that procedural code is the one true way? classes are procedural code in their member functions ... it's just that the whole entity is wrapped in a "safe" package for consumption really when you say such things as "oo programming is a mistake" you really dont give yourself any credibility here where your audience is largely made up from some of the best programmers in the world sheesh
l a u r e n wrote:
when you say such things as "oo programming is a mistake" you really dont give yourself any credibility here where your audience is largely made up from some of the best programmers in the world
Thank you, l a u r e n :)
l a u r e n wrote:
sheesh
:laugh:
I'd like to help but I don't feel like Googling it for you.
-
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 :):)
The book is called 'Code Complete'. You should buy this book, and work through it.
Christian Graus - C++ MVP
-
IMHO, if your team is determined to argue, they'll find something to argue about. Orthogonality should be a goal in and of itself - whether the code is orthogonal or procedural.
---- I just want you to be happy; That's my only little wish...
Shog9 wrote:
IMHO, if your team is determined to argue, they'll find something to argue about.
No doubt.
Shog9 wrote:
Orthogonality should be a goal in and of itself - whether the code is orthogonal or procedural.
I use the term in the sense of "keeping separate things separate". It does not seem reasonable to us to hang verbs underneath nouns - or nouns underneath verbs, for that matter. Procedural programming tends to keep the two separate. In one 25,000-line Pascal program we wrote some time ago, for example, we only had two source files, called "nouns" and "verbs". It was a remarkably convenient and effective organization. In case you haven't run across my standard dissertation regarding cookies and ovens and baking, I'll repeat it here: In the object approach, a cookie is an object, and an oven is an object. Fine so far. But should we say "cookie.bake(oven)" or "oven.bake(cookie)" or something else, like "abstract.bake(cookie,oven)". We think all these options are unnatural, and prefer this actual Plain English code:
A cookie is a...
An oven is a...
To bake some cookies in an oven...Where the nouns and the verbs are "related" to the verb in the routine header (the third line above), but do not "hang" underneath each other - or under some artificial abstract class - as they would in the object approach. And we find the syntax much easier to think about, type in, and read, to boot. 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...
-
I did not think I'd still read something like this today. Back to the 80s. :)
Pierre Leclercq wrote:
I did not think I'd still read something like this today. Back to the 80s.
As C. S. Lewis once said, "We all want progress, but if you're on the wrong road, progress means doing an about-turn and walking back to the right road; in that case, the man who turns back soonest is the most progressive."