Post by guest3456 » 12 May 2014, 12:06
bobc119 wrote:I am sure it is personal preference, but I am curious if there are sort of standard common practices amongst programmers, that may be helpful to non-programmers like myself.
everything is personal preference, but there good reasons as to why preferences have developed in certain ways
one such set of standards that i like is here:
http://www.koonsolo.com/news/dewitters-tao-of-coding/
bobc119 wrote:
where the one function may be a few hundred to a few thousand lines themselves. In my mind, this avoids global space as much as possible.
Is it better to instead split the function into many smaller functions, and call them from the label?
there are many reasons
1. its much harder to debug
2. its much harder to test
3. its much harder to maintain
4. you are probably repeating code
everyone falls in this trap and it takes conscious effort to keep refactoring the code. most of the time people won't worry about this, especially AHK scripters, because no one is testing their code. but when you have large codebases that you need to maintain, its a nightmare to try to read through a 1000 line function and then debug it. AHK scripts also don't write unit tests or use testing suites, so they aren't gonna bother. but when you have to maintain large commercial codebases you need to be able to know exactly where things are failling so you can fix bugs fast.
once you get into writing classes it is also important that each class adheres to the Single Responsibility Principle which will allow you to isolate variables similar to keeping the global namespace clean
bobc119 wrote:
Also, quite often I'll use functions within other functions, which seems frowned upon for some reason
no, what you've shown is the exact way to keep the functions smaller by separating concerns
http://en.wikipedia.org/wiki/Separation_of_concerns
from the author of the Linux operating system:
https://www.kernel.org/doc/Documentation/CodingStyle wrote:
Chapter 6: Functions
Functions should be short and sweet, and do just one thing. They should
fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
as we all know), and do one thing and do that well.
The maximum length of a function is inversely proportional to the
complexity and indentation level of that function. So, if you have a
conceptually simple function that is just one long (but simple)
case-statement, where you have to do lots of small things for a lot of
different cases, it's OK to have a longer function.
However, if you have a complex function, and you suspect that a
less-than-gifted first-year high-school student might not even
understand what the function is all about, you should adhere to the
maximum limits all the more closely. Use helper functions with
descriptive names (you can ask the compiler to in-line them if you think
it's performance-critical, and it will probably do a better job of it
than you would have done).
heres an example exercise that i had done a while ago while i was learning to code in TDD style, where you write tests BEFORE you write the code (probably should watch in fullscreen):
https://www.youtube.com/watch?v=Fm2Q-lJPgSg&hd=1
you may think that video is trivial but test-first coding (TDD) has become very popular recently because you will have a test suite which can pinpoint any bugs as you go along. plus you will be constantly refactoring the code into smaller pieces so it is easy to maintain and read. you can see starting at 5:20 in the video when i break the code into smaller functions. notice that even if the new functions are only a few lines long, i have broken them out because the main function was no longer "only doing one single thing". so i refactor the code and split into new functions, with explicit names explaining the 'one thing' that the function is meant to do
[quote="bobc119"]I am sure it is personal preference, but I am curious if there are sort of standard common practices amongst programmers, that may be helpful to non-programmers like myself. [/quote]
everything is personal preference, but there good reasons as to why preferences have developed in certain ways ;)
one such set of standards that i like is here:
http://www.koonsolo.com/news/dewitters-tao-of-coding/
[quote="bobc119"]
where the one function may be a few hundred to a few thousand lines themselves. In my mind, this avoids global space as much as possible.
Is it better to instead split the function into many smaller functions, and call them from the label? [/quote]
there are many reasons
1. its much harder to debug
2. its much harder to test
3. its much harder to maintain
4. you are probably repeating code
everyone falls in this trap and it takes conscious effort to keep refactoring the code. most of the time people won't worry about this, especially AHK scripters, because no one is testing their code. but when you have large codebases that you need to maintain, its a nightmare to try to read through a 1000 line function and then debug it. AHK scripts also don't write unit tests or use testing suites, so they aren't gonna bother. but when you have to maintain large commercial codebases you need to be able to know exactly where things are failling so you can fix bugs fast.
once you get into writing classes it is also important that each class adheres to the Single Responsibility Principle which will allow you to isolate variables similar to keeping the global namespace clean
[quote="bobc119"]
Also, quite often I'll use functions within other functions, which seems frowned upon for some reason[/quote]
no, what you've shown is the exact way to keep the functions smaller by separating concerns
http://en.wikipedia.org/wiki/Separation_of_concerns
from the author of the Linux operating system:
[quote="https://www.kernel.org/doc/Documentation/CodingStyle"]
Chapter 6: Functions
Functions should be short and sweet, and do just one thing. They should
fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
as we all know), and do one thing and do that well.
The maximum length of a function is inversely proportional to the
complexity and indentation level of that function. So, if you have a
conceptually simple function that is just one long (but simple)
case-statement, where you have to do lots of small things for a lot of
different cases, it's OK to have a longer function.
However, if you have a complex function, and you suspect that a
less-than-gifted first-year high-school student might not even
understand what the function is all about, you should adhere to the
maximum limits all the more closely. Use helper functions with
descriptive names (you can ask the compiler to in-line them if you think
it's performance-critical, and it will probably do a better job of it
than you would have done).
[/quote]
heres an example exercise that i had done a while ago while i was learning to code in TDD style, where you write tests BEFORE you write the code (probably should watch in fullscreen):
https://www.youtube.com/watch?v=Fm2Q-lJPgSg&hd=1
you may think that video is trivial but test-first coding (TDD) has become very popular recently because you will have a test suite which can pinpoint any bugs as you go along. plus you will be constantly refactoring the code into smaller pieces so it is easy to maintain and read. you can see starting at 5:20 in the video when i break the code into smaller functions. notice that even if the new functions are only a few lines long, i have broken them out because the main function was no longer "only doing one single thing". so i refactor the code and split into new functions, with explicit names explaining the 'one thing' that the function is meant to do