Page 2 of 2
Posted: Thu May 25, 2006 4:01 pm
by Flamie
I agree with you simple code important, but that doesnt mean it has to be short.
again its NOT about how long it is! you cant say my class is bad because its too long, if a lot of functions belong there then it will be long, if not it will be short.
I dunno but from what I see we're gonna have to agree to disagree on that matter, because I dont believe ALL the classes should be short, as it all depends on the kind of project and kind of class you make.
Posted: Thu May 25, 2006 4:03 pm
by Flamie
And it wasnt really the length of the class that made the bug hard to find, mostly the fact that it didnt give me an error or any indication on where the error could be.
Posted: Thu May 25, 2006 4:13 pm
by Christopher
jonra wrote:I just wouldn't break it up just to break it up at this point. I definitely wouldn't want to work on an application that had a class with 2000 lines, but I don't know I'd look to start breaking it up either. It'd be tough once it was written for me I guess, but I agree completely with what you're saying.
edit: Also it's kind of ironic that we've got this debate on a thread where the main problem was he couldn't easily debug the class because it was 2000 lines of code :p
Actually there is a lot of help for us programmers in these areas. A lot of very smart people have been thinking, writing and discussing the two problems that you are encountering. And lucky you, the only way you can really understand a programming concept is when you have a real problem that needs to be solved (and your toolbox is empty).
Your first problem is "...I don't know I'd look to start breaking it up either. It'd be tough once it was written..." well join the club because I get really reluctant and confused about how to do this too. Luckily there is a whole branch of programmerdom dedicated to this problem -- its called
Refactoringand there are a lot of resources online and some great books on the subject.
Your second problem is "but I don't know I'd look to start breaking it up either. " and it ends up those same smart people have come up with lists of things to check for -- they are called
Code Smells (horrible but descriptive name

) and the are many resources for them as well.
Hockey hates me talking about the "great thinkers" in our profession, but I would highly recommend standing on the shoulders of giants to get a better view of your own code and methodologies.
Posted: Thu May 25, 2006 4:31 pm
by MrPotatoes
jonra wrote:MrPotatoes wrote:(i said something)
Ok, kidding. I do agree with you - I just wouldn't break it up just to break it up at this point. I definitely wouldn't want to work on an application that had a class with 2000 lines, but I don't know I'd look to start breaking it up either. It'd be tough once it was written for me I guess, but I agree completely with what you're saying.
edit: Also it's kind of ironic that we've got this debate on a thread where the main problem was he couldn't easily debug the class because it was 2000 lines of code :p
honestly, i do most of my coding first in one file and about 2 maybe 3 functions. if i need a function from another area i copy it's functionality over. i develop in a component and document (on acual paper it's my dev notes) i comment like crazy and then i come back to it and meticulously break it up and make it faster/better blah blah blah.
this thread is funny. i need serious help with source control lmao
Posted: Thu May 25, 2006 4:58 pm
by n00b Saibot
A code smells too? eeeeeek! and it's really worse that code has stenches too! double eeek!
and there is more to it: ShotgunSurgery, InappropriateIntimacy, CodeDeodorant, TallerThanMe. i dunno where do they get these names

Posted: Thu May 25, 2006 5:16 pm
by Christopher
MrPotatoes wrote:honestly, i do most of my coding first in one file and about 2 maybe 3 functions. if i need a function from another area i copy it's functionality over. i develop in a component and document (on acual paper it's my dev notes) i comment like crazy and then i come back to it and meticulously break it up and make it faster/better blah blah blah.
Perhaps some programming tools made of bronze might be the next step for you ... just kidding ... I wish I understood half of what there is to know about things like Refactoring and Code Smells.

Posted: Fri May 26, 2006 4:26 am
by onion2k
MrPotatoes wrote:no matter which language i've written (C++/Java/PHP/C#/C) none of my files were longer than 500 lines. and this is 3D work, AI and some physics. but hey, if you wanna say that it might need 2K lines then so be it. i'm not gonna fight you on it. but out of all the complicated projects that i've ever been involved with none were that long.
The fact you break your code into various files is great, but don't kid yourself that makes it easier to understand. It doesn't. If anything, debugging an application that's spread out over lots of files is actually
more complicated than a single monolithic file, especially if the coder hasn't documented the file structure properly.
Also, 3D work is generally maths and API calls and very little else .. that's bound to be compact. Text manipulation, database work, web form stuff, that all grows much more quickly. Don't make the mistake of assuming a complex operation means lots of code. That's often not the case. I find simple, labourious tasks are actually more like to require the most lines of code.
Posted: Fri May 26, 2006 7:46 am
by Maugrim_The_Reaper
Just to chip in and annoy more people...
The fact you break your code into various files is great, but don't kid yourself that makes it easier to understand. It doesn't. If anything, debugging an application that's spread out over lots of files is actually more complicated than a single monolithic file, especially if the coder hasn't documented the file structure properly.
Oddly I would disagree. I've found debugging is far easier when classes are kept lean and mean. There are a few reasons I found this - if the bug occurs within a set behaviour, then I can track down where the behaviour originates quickly. If the behaviour results from several interacting classes, I will track across the interfaces with each. If the methods are kept short it's easier to navigate. Just my experience...
As for understanding - I dislike large classes where the bloat results from large methods. It makes a class difficult to read and follow. And it can often indicate the class is doing way too much, or its purpose has been too broadly defined. Taking an example, if I saw a game with a Player class I would make a few assumptions, the simplest being the Player class represents a Player (their data, and certain lookups). I would not expect a Player class to handle every player action/operation imaginable in the game. If it does I'd call it a procedural library wannabe and suggest it be made such or be broken down into smaller more focused classes.
Posted: Fri May 26, 2006 8:22 am
by BDKR
Maugrim_The_Reaper wrote:Just to chip in and annoy more people...
The fact you break your code into various files is great, but don't kid yourself that makes it easier to understand. It doesn't. If anything, debugging an application that's spread out over lots of files is actually more complicated than a single monolithic file, especially if the coder hasn't documented the file structure properly.
Oddly I would disagree. I've found debugging is far easier when classes are kept lean and mean. There are a few reasons I found this - if the bug occurs within a set behaviour, then I can track down where the behaviour originates quickly. If the behaviour results from several interacting classes, I will track across the interfaces with each. If the methods are kept short it's easier to navigate. Just my experience...
Actually Maug, you and he are talking about two seperate things. While you are talking about well considered and designed classes, he's merely talking about their location.
Posted: Fri May 26, 2006 8:23 am
by MrPotatoes
what he said.
like i said, if you want large source so be it. it's not my code. let it die. puh-leeeeeeeeze
what's funny is that no matter where i go (forums, parties, bar, colleges, family reunions) i always cause a stir. sry for that guys. get back to your normal scheduale

Posted: Fri May 26, 2006 8:34 am
by Maugrim_The_Reaper
Stupid me...

. Sorry.
Posted: Fri May 26, 2006 8:55 am
by sweatje
It the OP problem, I make it a habit to never close my php tags. My scripts generally look like
There are people who are pedantic and like to see the closing tag, so the actual strategy I use is to use #?> to close the script, i.e.:
Becuase the # is a comment, the php mode does not really close, and you do not end up with the potential for inadvertant whitespace.
Posted: Fri May 26, 2006 9:21 am
by MrPotatoes
i've actually seen that and heard it was faster or something.
i guess you close it out in like a footer or something? i personally don't do that. i'm one of those people that need to see it. otherwise if i try that i might screw it up somewhere lol
Posted: Fri May 26, 2006 9:30 am
by sweatje
MrPotatoes wrote:i guess you close it out in like a footer or something?
Nope, I never close it out. Closing the php tag is purely optional, and I choose not to do it (mainly from the potential for inadventant whitespace in include files phenomina).
Posted: Fri May 26, 2006 9:42 am
by jonra
Your first problem is "...I don't know I'd look to start breaking it up either. It'd be tough once it was written..." well join the club because I get really reluctant and confused about how to do this too. Luckily there is a whole branch of programmerdom dedicated to this problem -- its called
Refactoringand there are a lot of resources online and some great books on the subject.
I've read about refactoring, although not what I would consider extensively at all, but I'd argue why still. If I have a class that long (again, I don't - most of my code is broken up into includes that rarely top even 300 lines, as we write small-mid sized apps only) - why break it up if it's working for me? I guess I'm not sure on the math really... if there's an algorithmic problem in the design that may hinder performance I'd obviously want to look at changing my method, otherwise I guess I'd have a hard time being convinced I should go through a process to break everything up.
I'm also fairly new to web development, and most of my knowledge was in C++ before this world - One of my major concerns is software life cycle - as far as the actual life of a program after release. With the way things move in this world, and the number of new languages and methodolgies we constantly see, I always worry about even putting much time into 'fixing' an application that may not be broken in the first place save bad design. I know that I've already written an app or two that I ended up implementing a completely different method for the same application because of changes in the industry.
plus, with PHP it feels like the changes with each version make it hard to get true backwards compadability - Again, I'm only about a year into this world of development, so I'd love to hear your thoughts on that subject as it's still kind of murkey for me.
Your second problem is "but I don't know I'd look to start breaking it up either. " and it ends up those same smart people have come up with lists of things to check for -- they are called
Code Smells (horrible but descriptive name

) and the are many resources for them as well.
This is new to me, I will read up and thanks for the link
Hockey hates me talking about the "great thinkers" in our profession, but I would highly recommend standing on the shoulders of giants to get a better view of your own code and methodologies.
I think any good programmer does this by their nature. I've always felt that a cocky programmer who doesn't want to hear someone trashing the way they do things isn't as good of a programmer as they could be. Thick skin is important in this business, and I don't mind hearing new ideas even if I've come to the realization that the way I've done things was bad design.
Nope, I never close it out. Closing the php tag is purely optional, and I choose not to do it (mainly from the potential for inadventant whitespace in include files phenomina).
This is also new to me - I close out tags always, outside of the possible use of HTML outside of your PHP, is there anything inherintly wrong with not closing the tag?