Quote:
Originally Posted by meynaf
Arguments from authority never work on me.
|
There are people that have a bit more experience in programming than you. And me, of course. These aren't my advices, actually. You can check a couple of other sources if you like, or don't trust me.
Frankly, you have no clue.
Quote:
Originally Posted by meynaf
Is THAT the way of coding you want ME to use ??
|
I want you to comment what's worth commenting, and use clear code structure otherwise. I can only repeat: Many comments are good, code requiring many comments is bad. Your "anti-style" requires many comments, which is bad. Instead, comment non-obvious stuff.
Quote:
Originally Posted by meynaf
The assembler can *not* do it for me. Does it fetch these values automatically without me having to provide some include files ? No, it does not.
|
Include files are fine. Where is the problem with that? They modularize the code.
Quote:
Originally Posted by meynaf
... and are obvious, but don't support your point in any manner.
This strategy is called the strawman fallacy.
I have never written such bogus comments such as you show above.
|
Code:
move.l $18(a0),a0 ;cl_super
is a bogus comment. Just write the label. Be done with it. This comment is not needed, and pointless. Use the label in first place, that's why we have include files.
Quote:
Originally Posted by meynaf
Tell that to all the ones using it. You'll have many foes then.
Not that i'm using it myself, i wrote my own many years ago.
|
Until you write code within a team, or need to maintain code from somebody else.
Quote:
Originally Posted by meynaf
This is exactly the reason why the assembler should compute the size of branches, not me.
|
Nobody should. It doesn't really matter.
Quote:
Originally Posted by meynaf
Algorithms make programs fast. Micro-optimisations make them even faster. My picture viewer is the fastest currently available, and it's not for nothing.
|
You look at the wrong side of the problem. The instructions aren't the problem. You loose the full picture the way you look at the problem, and that's the danger.
Quote:
Originally Posted by meynaf
They are perhaps unreadable and unmaintainable for you, but it perfectly suits me. Sorry if i can do things you can't 
|
Leave the program aside, look at it in 5 years from now. Live and learn. That's all I can tell. Give the program to somebody else, ask somebody else to maintain it, or to debug it.
Quote:
Originally Posted by meynaf
Yes it is more work, and no the invested time doesn't pay.
I know and have tried both options. Can you say the same ?
|
Yes, I can say the same. I started this way, more than 30 years from now, and I left this behind, for the reasons I gave. This "anti-style" might work out for a while, but sooner or later, it becomes a maintenance nightmare.