ok what are the rules
-
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.
-
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.