quote:Original post by flangazor I personally hate writing functions that are only called once. In fact, I should have probably reworded my initial statement to say "people shouldn't write functions that are only called once"

That's getting even more dogmatic. If you were in an interview situation would you suggest that as being a good coding convention? What if they responded by saying 'And if it's only called once or twice? Or three times?'

Breaking large functions up into smaller functions is a key starting point into rearranging code, making it flexible, being able to move functions around that really should be on a different class, or higher or lower down an inheritance structure, doing away with duplicated code, having functions with meaningful names so that you need less comments, being able to profile smaller sections etc. etc.

If you've got some spare cash, read Refactoring by Martin Fowler for more info on the above way of looking at and working with code. The link is the cheapest I could find in the UK if you're still in London. Otherwise get it from the library (c:


[edited by - petewood on June 19, 2003 5:47:37 AM]

Classes are not OOP, but a way to achieve it. Hanging on IRC in dev channels all day long, I''ve seen many people using classes in a totally non-OOP way. At the same time, the Quake 3 source looks OO to me, and it''s C...

C can do most things C++ do, the only difference is that they are often easier to implement in C++ since additional tools are given to obtain an OO design. Inheritance could be done with simple function pointers. You''d get basically the same result, except it''s much nicer when it''s part of the language as it results in faster development and easier maintenance.

One last thing : the tools you use also depend of the task, I personally like C++ for large projects as I find maintenance and management easier. At the same time, maybe if Visual Studio worked only for C (I know, I know, you can replace the compiler), I might end up using C rather than C++ just cause it''s more convenient and easier to manage ;p

Oh and don''t try to convince Edward, the C vs C++ war will never end anyway ;p

And while we talk about this, anybody into AOP?
(aspect oriented, for people who never heard of it)

quote:Original post by mputters
Classes are not OOP, but a way to achieve it.
[...]
C can do most things C++ do, the only difference is that they are often easier to implement in C++ since additional tools are given to obtain an OO design.

Isn''t that just a paraphrasing of what I said earlier?

quote:
Inheritance could be done with simple function pointers.

Inheritance in C has to be done by placing the base struct as the first member of the inheriting struct (gets more complicated for MI). Then, you can pass any derived to a function expecting a base by using an explicit cast within the call. To get dynamic despatch, you have to do something like tagging to indicate the actual type of the pointee. I''ve demonstrated all this elsewhere on the forums.

quote:Original post by mputters
And while we talk about this, anybody into AOP?

What of it?

Well sorry for not reading carefully all of your wonderful posts and knowing them by heart ;p

quote:Original post by mputters
Well sorry for not reading carefully all of your wonderful posts and knowing them by heart ;p

It''s considered polite to familiarise yourself with what''s already been said before entering a discussion.

quote:Original post by petewood
That''s getting even more dogmatic. If you were in an interview situation would you suggest that as being a good coding convention? What if they responded by saying ''And if it''s only called once or twice? Or three times?''

If it was an interview, I wouldn''t bring it up because they don''t want to hear that. Just like how I wouldn''t say "SGML ruined the potential of the web" or "if you can''t be part of the solution, there''s money to be made being part of the problem."

quote:Breaking large functions up into smaller functions is a key starting point into rearranging code, making it flexible, being able to move functions around that really should be on a different class, or higher or lower down an inheritance structure, doing away with duplicated code, having functions with meaningful names so that you need less comments, being able to profile smaller sections etc. etc.

My beef is with turning something I would write:
//Initialise part a
{
...//20 lines
}
//Initialise part b
{
...//17 lines
}
//Initialise part c
{
...//24 lines
}

into three function calls. The code doesn''t disappear; just moved. In my version, the comments won''t become obsolete unless the whole function is changed -which means your sub-functions would be changed anyway. If you subscribe to a policy of ''code as documentation'' there may be some validity to your claim but it would be a case of your dogma vs. mine. Later, if you think the code would be useful elsewhere you can refactor. To twist a quotable to do my bidding: ''The branch of all evil is premature refactoring.''

quote:
If you''ve got some spare cash, read Refactoring by Martin Fowler for more info on the above way of looking at and working with code. The link is the cheapest I could find in the UK if you''re still in London. Otherwise get it from the library (c:

My boss has a copy in his room and I''ve skimmed it. I''ll borrow it if you think its worth it. I have a few other books in queue though so it may have to wait.

Thanks for doing the legwork, though.

quote:Original post by flangazor
If it was an interview, I wouldn''t bring it up because they don''t want to hear that. Just like how I wouldn''t say "SGML ruined the potential of the web" or "if you can''t be part of the solution, there''s money to be made being part of the problem."

(c:

quote:
To twist a quotable to do my bidding: ''The branch of all evil is premature refactoring.''

/c:

quote:My boss has a copy in his room and I''ve skimmed it. I''ll borrow it if you think its worth it. I have a few other books in queue though so it may have to wait.

It is mainly made up of a catalog which can be skimmed. There is an introductory article and an example which can be read in an hour or so. There are follow up articles after the catalog as well which are more in depth and good food for thought. You can get the gist from the first example and a quick skim through those refactorings which have immediately made sense to you.

quote:Thanks for doing the legwork, though.

You''re welcome.

quote:flangazor

quote:Way Walker
Don''t know if I''ve read that specifically, but I generally agree with Stroustroup (and I think C++ has done well with the restrictions it''s had to work with). The only way I can see myself disagreeing is if it implies that something is "more OO" if it uses classes and such, or if it says that OO is difficult in languages like C.

What is stopping you from reading it?

Nothing, I just figured it wouldn''t have anything I hadn''t heard a hundred times before. I just read it, and it didn''t really have anything new. I was impressed (I always am) at how impartial Stroustrup is when talking about C++. He freely pointed out areas where other languages had useful features that C++ did not (exceptions and parameterized types are the ones that stick out in my mind) (yes, I realize C++ has those now, but they do feel "tacked on" rather than part of the language, but, again, they are really well done considering the constraints C++ is working with). If it weren''t Stroustrup, I would have taken some of his comments about C and Smalltalk as attacks, but really he''s just stating a fact (it''s true, neither C''s nor Smalltalk''s type system stops you from applying a function/sending a message to the wrong type. Whether or not this is an issue in practice is another issue.).