11 May, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
im just full of questions:

Ok, i've noticed how cramped merc.h is, and was wondering if its worth breaking everything up into a more practical format, such as, making multiple headers:

character.h would have all the needed sctructures and prototypes, globals etc.
object.h -> etc.
descriptor.h -> etc. (ok, you get the idea)

of course, it is nice to have just one ref to merc.h in each .c file, but then again, i was wondering if anyone else took the time to try to make it a bit more uniform?
11 May, 2009, Lyanic wrote in the 2nd comment:
Votes: 0
Exactly that has been done in The 7th Plane's code. So, the short answer is: Yes, it is worth it.
11 May, 2009, JohnnyStarr wrote in the 3rd comment:
Votes: 0
cool, thanks. I thought i might be crazy for a minute. :stare:
12 May, 2009, Hades_Kane wrote in the 4th comment:
Votes: 0
It takes me like two seconds to search for "act_" or "plr_" or "is_" or "gsn_" to get to the general section I need to be in. I know everything will be declared in there, so I know right what file to open.

So, I guess it just depends on the person. What might be right for me or someone else might not be right for you, so if you feel like something is worth doing, then do it. You don't need anyone else's confirmation on something like that. I could understand a question as to whether or not something would break something, but that seems to be just a stylistic questions, almost akin to asking "Would be it be better to have this channel's color {b or {y". So yeah, if you feel it would be worth it, go for it. Me personally, I'd find it annoying.
12 May, 2009, David Haley wrote in the 5th comment:
Votes: 0
With a decent editor that implements any kind of code awareness, be it like Visual Studio's Intellisense or vim/emacs tag handling, you can also instantly jump to the right file without even knowing the filename.

It's generally considered to be poor form to have a giant file that you dump everything into. It makes a mess, it's unwieldy, it makes it harder to distinguish interface from module internals, etc. It's convenient in some respects (don't have to think about which file to include, "Just [Include] It") but IMO there are these qualitative disadvantages (qualitative in that it's hard to numerically benchmark them).
12 May, 2009, Lyanic wrote in the 6th comment:
Votes: 0
David Haley said:
It's generally considered to be poor form to have a giant file that you dump everything into. It makes a mess, it's unwieldy, it makes it harder to distinguish interface from module internals, etc.

Thank you. That's exactly my sentiment regarding the merc.h matter.
12 May, 2009, Hades_Kane wrote in the 7th comment:
Votes: 0
David Haley said:
It's generally considered to be poor form to have a giant file that you dump everything into. It makes a mess, it's unwieldy, it makes it harder to distinguish interface from module internals, etc.


If I'm not releasing the game, no one else will be messing around in the code, and I prefer it one way, who cares if its "poor form"?
12 May, 2009, David Haley wrote in the 8th comment:
Votes: 0
Well, there's a practical reason why things are considered poor form – it's not just some abstract sense of general aesthetics. But you are correct that the only person affected is yourself. That said, the question was asked not about what you should do in your own coding but what about other people should do, hence why I believe people should care if it's poor form when answering the question as posed. :smile:
12 May, 2009, Hades_Kane wrote in the 9th comment:
Votes: 0
David Haley said:
Well, there's a practical reason why things are considered poor form – it's not just some abstract sense of general aesthetics. But you are correct that the only person affected is yourself. That said, the question was asked not about what you should do in your own coding but what about other people should do, hence why I believe people should care if it's poor form when answering the question as posed. :smile:


If you wouldn't mind enlightening me as to what practical reason there might be for it to be considered poor form, you might change my mind :p

Afterall, I was convinced well enough over the /n/r vs /r/n thing I went through and fixed all instances of that in my code, so I'd be glad to hear what is wrong with having all of that in one file.
12 May, 2009, David Haley wrote in the 10th comment:
Votes: 0
Well, I alluded to it already. Just as we separate implementation source code (.c files) into separate files to increase manageability, it is wise to separate the interface source code (.h files) into separate files. This increases modularity and forces the programmer(s) to think more about writing more general-purpose code – or, put another way, less ad-hoc solve-this-very-particular-problem-right-now code.

By clearly separating modules, and grouping functionality into said modules, it is easier to see opportunities to refactor functions into common functions. Reducing code duplication is good for many reasons which I won't go into here (hopefully we all already agree that duplicating code is bad).

Having one giant file makes it difficult to redistribute smaller parts of it, as one must start worrying about which segments of that file are relevant, etc.

Having several files makes dependencies far more clear between modules, whereas a giant lump says nothing at all about which modules depend on which other modules. Seeing the dependencies means far less time must be spent figuring them out from scratch.

A purely practical argument is that when you have one giant header file, any change to it forces a recompilation of the entire program. This is annoying, but isn't IMO a contributor to the "bad form" argument.

Basically, anything that goes against cleanliness and clarity is bad because it makes the code harder to read and therefore harder to maintain (and therefore bugs are easier to introduce), not only by yourself some time from now but also and especially for other people. As soon as understanding is impacted, people are more likely to make mistakes. So yes, if it's just you, you're only hurting yourself (and, well, people who depend on you to write good code quickly). But really, one should always be in the habit of writing good code – good code should come naturally to you, just like good spelling, so that when it really does matter that you know how to write code, you don't have to think about it anymore.

Of course, this is all very different from \n\r vs. \r\n, because in that case one answer is objectively wrong by definition (much as it would be wrong to say that sentences end with parentheses and not periods), whereas "good practice" is a far more qualitative argument that can only be understood, perhaps, after having seen the effects of bad practice when compared to good practice. The funny thing about good practice is that you don't really notice its presence, whereas bad practice makes itself known all too well in the form of difficulty of maintenance, bugs due to misunderstandings, and so forth.
0.0/10