The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
It sounds like you support functions with 1000 lines over 15 lines. Extracting out discrete segments of logic into non-public methods/functions not only improves readability but allows you to abstract "complex logic" into an understandable name so new developers can digest it easier.
A caveat, as always, especially since you mention C: If it's for a functional performance requirement, I can't really fault massive functions. I can't seem to find the article but I remember years ago a game engine had to collapse its entire render stack into a single function to improve performance.
If your slogan was "no functions over 250 lines", I'd vote for you Oooo, or "Even books have chapters."
That wouldn't help, you don't vote for Kings.
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
I am actually beginning to hate C++ as well, but the reasons you mention have nothing to do with the language. Try reading some typical Java "enterprise" code and finding a method that actually does something.
Sorry for mentioning something simplistic, but I think immediately about call graphs …
When I used VC++ 4 or 5 I was extremely impressed by the call graph features … back then ,
I found them very handy, of course … I missed them in early VC#, and they resurfaced
at some point in VC# editions (in last 10 years I think ...), BR
In my younger days, I was very eager about call graphs myself. Well, that was in the days when you could dive into, say, an OS and understand every detail of it.
Then I started working with communication protocols, and it was still in the days when we believed that the OSI model were for real, with its service APIs and layer borders serving as firewalls both upwards and downwards, and protocol definitions independent of service APIs. But most of all: You had no control over your peer. You had to program according to service and protocol definitions, inside the black box. We used those principles as design guidelines even for non-communication software.
When you are in a firewalling black box, you shall not be concerned with how that service you are invoking fulfills it task. You shall not know the context in which the user of your service offering operates. And you shall send and receive protocol elements without regard for how your peer does his processing. For the in-layer code, OO encapsulation hides so much that we think of object methods almost as as "primitives", not some deep well of calls into calls into calls.
If you are into the telecommunication way of programming, you essentially make all your implmentation designs (and realizations) as finite state machines. Then there is very little left for the call graphs to do. I am no longer programming communication protocols, but I've fallen into the habit of FSM style and layered design; now that you mention call graphs, to me that is a long lost memory. But I do not miss it.
If you are into the telecommunication way of programming, you essentially make all your implementation designs (and realizations) as finite state machines. Then there is very little left for the call graphs to do.
good point indeed … I used FSM's years ago in text analysis and this reminds me somewhat vaguely about cases of equivalency between FSM and grammars … a grammar looks like a tree so in such cases a call graph would apply … Perhaps it is difficult/impossible to generalize, BR