|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On November 12 2013 01:52 Yoshi- wrote:Show nested quote +On November 11 2013 07:30 sluggaslamoo wrote:
If you have any functions that are longer than 10 lines seriously have a look at them and see if you can't break them down. Most of my functions are 1-3 (ruby) lines long, this is due to functional programming though, I'd say for PHP they should float between 3 to 5 lines on average.
Yea that is bullshit I all up for splitting code into smaller part, but saying that you should average between 3 to 5 lines is just ridiculous
Yeah, that seems like the strangest advice ever. If you have most of your functions 1-5 lines long and are working on actual project, not some proof-of-concept code, you are most likely writing bloated and unreadable code, where the actual logic is hiding behind unnecessary numbers of artificial functions.
|
On November 12 2013 07:16 Frigo wrote:Show nested quote +On November 12 2013 02:37 Manit0u wrote:
And remember, extends are evil. Interface inheritance > implementation inheritance. components > delegation > mixins > interfaces > inheritance
As wrong and simplifying as the original post. The original might be a nice rough guideline, but that is it. There are instances where the order is completely reversed. And they are not exceptions. I am not even sure they are necessarily majority due to complexities of all possible orderings.
|
On November 12 2013 11:54 phar wrote:Show nested quote +On November 12 2013 11:41 Cyx. wrote:On November 12 2013 11:27 phar wrote:Oh wait nevermind you're this guy: On April 30 2013 10:57 sluggaslamoo wrote:
As a whole, I'd say 95% of all developers in the world are absolutely atrocious because of the reason you gave. A very tiny fraction of developers actually know how to write good code and engage in computer science. I do not work with those kinds of developers and neither do my workmates because they are simply a waste of time.
I don't know why this is my loss, I get paid a substantially higher amount compared to your developers and get to work in a really good environment because of said reasons. Developers like yours would not even pass the interview of some of the companies I've worked in.
So did like three whole days of posts get burned out of this thread, or is that from somewhere else? Because I went looking for context on that quote and there is nothing for the day before that date to the day after that date in this thread... and now I feel like I missed a good flame war Sorry, unrelated thread from awhile back. http://www.teamliquid.net/forum/viewmessage.php?topic_id=410026¤tpage=18#341
I like his very last post though, it's very hard to fault and rings very true in my ears.
http://www.teamliquid.net/forum/viewmessage.php?topic_id=410026¤tpage=22#421
|
Yes I agree with many of his arguments. I'm just against his holier-than-thou and dismissive delivery. What drove the nail into the coffin for me was calling my co-workers inferior and lower paid, without knowing where I work or how much I make. That shows an astounding level of arrogance.
|
On November 12 2013 13:41 mcc wrote:
Yea that is bullshit
I all up for splitting code into smaller part, but saying that you should average between 3 to 5 lines is just ridiculous
Yeah, that seems like the strangest advice ever. If you have most of your functions 1-5 lines long and are working on actual project, not some proof-of-concept code, you are most likely writing bloated and unreadable code, where the actual logic is hiding behind unnecessary numbers of artificial functions.
It's not bullshit, and it's not strange advice. Sluggaslamoo idea's are coming from a book called Clean Code by Robert C. Martin. I'll let you Google him to figure out whether or not you should follow his advice.
In his book, he mentions some things about functions:
- Functions should be tiny.
- Functions should do one thing
- One Level of Abstraction per Function
- The Stepdown Rule
Functions should be tiny because it actually makes code a lot easier to debug, follow, and read. If your "actual logic is hiding behind an unnecessary number of artificial functions" then you're not doing it right. This is tightly coupled with the idea that there should be one level of abstraction per function. For example - consider this code:
void ExecuteCommand(char *command)
{
ParseCommand(command);
ValidateCommand(command);
CreateCommandTree(command);
for( int i = 0; i < strlen(command); i++)
command[i]++;
}
void ParseCommand(char* command)
{}
void ValidateCommand(char* command)
{}
void CreateCommandTree(char* command)
{}
Isn't the for loop in the ExecuteCommand function a little odd? That's what one level of abstraction per function means. ExecuteCommand is a high-level function - we shouldn't do char-by-char string manipulation in it because it breaks the flow of the code. The step-down rule says that i shouldn't have to hunt around the code to find functions that I need. ParseCommand should immediately follow ExecuteCommand... etc etc. That way, code reads like a "book." You can see that structure in the way functions are defined in my code above.
These are just some of his ideas. Now - there are some extremely successful pieces of software that don't do these things. I'm looking at fork.c in the linux kernel code and there's a function that's 60+ lines long. It's also ugly as hell, and I can't immediately see what it's doing, whereas my code - simple as it may be - is somewhat obvious. "Well first he's parsing the command... then validating it... then creating some sort of 'command tree'."
There's a reason Sluggaslamoo is saying what he's saying. He's not talking out of his ass. The fact that you didn't know he was talking about Clean Code shows that you aren't as read up on the literature of writing code as well as you should be. Pragmatic Programmer and Clean Code should be part of any programmer's arsenal - if only to broaden your horizons.
As for what he posted in the other thread, I wholeheartedly agree. The best programmers do dedicate their lives to mastering the art. In fact, in his book Outliers, Malcolm Gladwell talks about how it takes at least 10,000 hours of doing something to truly master it. You may believe that Bill Gates got lucky in making his fortune, but the truth is that he spent thousands of hours programming (which he talks about in his book).
|
|
|
On November 12 2013 15:50 Abductedonut wrote:
It's not bullshit, and it's not strange advice. Sluggaslamoo idea's are coming from a book called Clean Code by Robert C. Martin. I'll let you Google him to figure out whether or not you should follow his advice.
In his book, he mentions some things about functions:
- Functions should be tiny.
- Functions should do one thing
- One Level of Abstraction per Function
- The Stepdown Rule
I just (re-) read that chapter of the book.
Here's the thing: These guidelines you mention are good. And sluggaslamoo's first statement on the issue wasn't bad either as he merely suggested to have a look at larger functions and see if they can't be refactored.
However then it spiraled out of control and people started talking in absolutes. Absolutes are always wrong.
The rule is not "your functions should be 3-5 lines or else you're stupid". It's "try to keep things as simple as you can".
Have a look at your largest functions, see if you can split them up meaningfully and with adequate effort. If you can't, don't. Occasionally come back and have a look at them again.
For example, I've written functions that check for ~20 nontrivial rules. Even if I split it up into 20 seperate functions, I still have one function with 20 lines calling each of the rule checks (and zero code reuse anyways). The proper way of refactoring it would be to develop a way to specify these rules in an XML file and write code to load these rules and apply them in a loop.
That's a ton of work, hardly worth the gain as these rules are never going to change.
|
The idea of having a function do one thing is nice. Especially for large projects.
What's the rule for files of code? eg. module1.py module2.py (replace py for any other language)
One file for one module seems nice but then you realize that the server has many sub-modules. I can't think of any rules for which submodules to use.
While we're talking about simplicity, I find that it's impossible to scale up large projects until I work in an IDE like eclipse that lets me see the header comments of a function by hovering over it, and by navigating to an implementation using ctrl+click. I tried creating a project in python without an IDE because Pyscripter and pycharms and idlex were buggy, but then it was impossible to keep track of everything.
The best practices are useless if you don't have the development environment to use them sine they just make the job a lot harder.
For example, I don't think vim offers code navigation. At least not out of the box.
If your company doesn't suggest that most people use an IDE with code navigation, then many people may not use one and you end up with this kind of code. I find using an IDE has made my functions 10x smaller and much more readable.
fuck: late for class! Sorry if something wasn't clear.
|
On November 12 2013 15:50 Abductedonut wrote:Show nested quote +On November 12 2013 13:41 mcc wrote:
Yea that is bullshit
I all up for splitting code into smaller part, but saying that you should average between 3 to 5 lines is just ridiculous
Yeah, that seems like the strangest advice ever. If you have most of your functions 1-5 lines long and are working on actual project, not some proof-of-concept code, you are most likely writing bloated and unreadable code, where the actual logic is hiding behind unnecessary numbers of artificial functions. It's not bullshit, and it's not strange advice. Sluggaslamoo idea's are coming from a book called Clean Code by Robert C. Martin. I'll let you Google him to figure out whether or not you should follow his advice. In his book, he mentions some things about functions: - Functions should be tiny. - Functions should do one thing - One Level of Abstraction per Function - The Stepdown Rule Functions should be tiny because it actually makes code a lot easier to debug, follow, and read. If your "actual logic is hiding behind an unnecessary number of artificial functions" then you're not doing it right. This is tightly coupled with the idea that there should be one level of abstraction per function. For example - consider this code:
void ExecuteCommand(char *command)
{
ParseCommand(command);
ValidateCommand(command);
CreateCommandTree(command);
for( int i = 0; i < strlen(command); i++)
command[i]++;
}
void ParseCommand(char* command)
{}
void ValidateCommand(char* command)
{}
void CreateCommandTree(char* command)
{}
Isn't the for loop in the ExecuteCommand function a little odd? That's what one level of abstraction per function means. ExecuteCommand is a high-level function - we shouldn't do char-by-char string manipulation in it because it breaks the flow of the code. The step-down rule says that i shouldn't have to hunt around the code to find functions that I need. ParseCommand should immediately follow ExecuteCommand... etc etc. That way, code reads like a "book." You can see that structure in the way functions are defined in my code above. These are just some of his ideas. Now - there are some extremely successful pieces of software that don't do these things. I'm looking at fork.c in the linux kernel code and there's a function that's 60+ lines long. It's also ugly as hell, and I can't immediately see what it's doing, whereas my code - simple as it may be - is somewhat obvious. "Well first he's parsing the command... then validating it... then creating some sort of 'command tree'." There's a reason Sluggaslamoo is saying what he's saying. He's not talking out of his ass. The fact that you didn't know he was talking about Clean Code shows that you aren't as read up on the literature of writing code as well as you should be. Pragmatic Programmer and Clean Code should be part of any programmer's arsenal - if only to broaden your horizons. As for what he posted in the other thread, I wholeheartedly agree. The best programmers do dedicate their lives to mastering the art. In fact, in his book Outliers, Malcolm Gladwell talks about how it takes at least 10,000 hours of doing something to truly master it. You may believe that Bill Gates got lucky in making his fortune, but the truth is that he spent thousands of hours programming (which he talks about in his book).
Why should I read the book, when everything you said is obvious and I knew that already without ever reading that book ? If you think enough about what you are doing when programming, you will come up with those guidelines yourself. Of course reading that book might save you time or point you in the correct direction faster, but they are not required. The fact that you think that those ideas are unavailable to anyone who did not read the book is rather telling. And all those guidelines are actually complex. You need to actually understand them, when they apply, when to ignore them,.... All those guidelines are tradeoffs. No non-trivial programming guideline is without tradeoff. The guideline about minimizing function length and complexity runs against multiple other guidelines that have their own strong rationale. Your job as a programmer is not to know and use those guidelines, but knowing when they are applicable and when to ignore them and how to balance the conflicting ones in current context.
I am not disagreeing with the general ideas. I am disagreeing with the specific metric of "small". I encountered too many functions that were longer than 5-10 lines and any further decomposition would make the code less readable. You end up with artificially named functions that are reusable only rarely and barely. Also this rule depends heavily on the language used.
I am also disagreeing with blanket absolute guidelines. Programming guidelines require understanding of context and applicability and I suspect none of those guidelines can be transferred to a person without enough programming experience. I would actually say that reading book explaining them is helpful only if you are already on the cusp of discovering them yourself, but that is just my hypothesis. Basically the whole thing is more complex than simple guidelines that are always applicable.
Just to point it out on the specific example. The minimizing function complexity guideline runs against "locality", which is one of the most important guidelines of team programming. Code implementing a use-case should be as concentrated as possible so anyone changing that code, no matter how uninformed and bad will have all the information necessary for that change right in his face thus making errors less likely. It also runs a risk of merging execution sequences that never should have been merged, because again those merged execution sequences make it more likely for a programmer implementing change request to only take into account one of the merged use-cases, but changing unintentionally both. It also goes against readability in many instances. Different people have different notions of readability, but multiplying function beyond necessity decreases readability for most people. And of course those rules I mentioned have to be balanced against multiple other rules and so on. It is all about balancing conflicting requirements. Simple solutions are always false promises.
|
On November 12 2013 23:15 mcc wrote:
You end up with artificially named functions that are reusable only rarely and barely.
Well, the point in this case isn't reusability, it's readability. It doesn't matter if a function is used only once if it makes program flow more readable. You're right that it's not always a good idea to split up a function just because it has more than 5 lines of code, but I definitely don't think one should shy away from refactoring logic into smaller functions just because you see no reason to use said function anywhere else. I would say, anywhere you need comments to make it immediately clear what a bunch of code is doing, it might be a better idea to remove the comment and make it into a function with a fitting name instead.
|
On November 13 2013 01:05 Tobberoth wrote:Show nested quote +On November 12 2013 23:15 mcc wrote:
You end up with artificially named functions that are reusable only rarely and barely.
Well, the point in this case isn't reusability, it's readability. It doesn't matter if a function is used only once if it makes program flow more readable. You're right that it's not always a good idea to split up a function just because it has more than 5 lines of code, but I definitely don't think one should shy away from refactoring logic into smaller functions just because you see no reason to use said function anywhere else. I would say, anywhere you need comments to make it immediately clear what a bunch of code is doing, it might be a better idea to remove the comment and make it into a function with a fitting name instead.
I am not saying you should shy away from considering it. I am saying there are multiple other things to consider and you should understand that nearly always it is a tradeoff with some other potentially valuable property. You might decide that those properties are not as important in your current situation. But absolute statements that they are never important is what I am arguing against.
Sometime you need comments because the algorithm is not clear due to for example speed concerns. You could argue that it should go into documentation and not a comment. But such comment is not an indication that you can move it to some other function, quite often it is sign that you should absolutely not do that or that it is impractical.
EDIT: Plus my main argument in part you quoted was also readability, reusability was only sidenote to underscore how useless it is sometimes to decompose functions as you gain neither. But big number of artificial functions that do not do anything that can be described in reasonable name and were created purely because it was possible to split original function can also affect readability negatively. And frankly in more than few occasions those decompositions are nothing more than exactly that. In some languages 1-3 lines is enough to express some non-trivial constructs. In some it is basically impossible.
|
I'm learning Clojure since the only lang I knew before was Lisp (just a little), but it is hard for me to practice.
But there isn't a lot of exercises available and all I try to do seems too complex for what I can do.
What todo, should I just read books? It is a little boring, looks like that I'm not learning a lot and I forget easily. I started to get codes from the internet and trying to break down to understand what is happening, isn't the fastest way neither the easiest, but is a little more action 
Also, I'm learning just for fun, that is way I'm trying Clojure (syntax from non-lisp scares me)
|
On November 13 2013 01:40 pedrlz wrote:I'm learning Clojure since the only lang I knew before was Lisp (just a little), but it is hard for me to practice. But there isn't a lot of exercises available and all I try to do seems too complex for what I can do. What todo, should I just read books? It is a little boring, looks like that I'm not learning a lot and I forget easily. I started to get codes from the internet and trying to break down to understand what is happening, isn't the fastest way neither the easiest, but is a little more action Also, I'm learning just for fun, that is way I'm trying Clojure (syntax from non-lisp scares me)
that's quite a unique way to get started lol
|
On November 13 2013 01:54 freelander wrote:Show nested quote +On November 13 2013 01:40 pedrlz wrote:I'm learning Clojure since the only lang I knew before was Lisp (just a little), but it is hard for me to practice. But there isn't a lot of exercises available and all I try to do seems too complex for what I can do. What todo, should I just read books? It is a little boring, looks like that I'm not learning a lot and I forget easily. I started to get codes from the internet and trying to break down to understand what is happening, isn't the fastest way neither the easiest, but is a little more action Also, I'm learning just for fun, that is way I'm trying Clojure (syntax from non-lisp scares me) that's quite a unique way to get started lol
Well, I started with Lisp but then I learned about Clojure that can use Java Libraries and I thought that could be easier/more useful.
But I'm just shooting in the dark
welp
|
On November 13 2013 01:55 pedrlz wrote:Show nested quote +On November 13 2013 01:54 freelander wrote:On November 13 2013 01:40 pedrlz wrote:I'm learning Clojure since the only lang I knew before was Lisp (just a little), but it is hard for me to practice. But there isn't a lot of exercises available and all I try to do seems too complex for what I can do. What todo, should I just read books? It is a little boring, looks like that I'm not learning a lot and I forget easily. I started to get codes from the internet and trying to break down to understand what is happening, isn't the fastest way neither the easiest, but is a little more action Also, I'm learning just for fun, that is way I'm trying Clojure (syntax from non-lisp scares me) that's quite a unique way to get started lol Well, I started with Lisp but then I learned about Clojure that can use Java Libraries and I thought that could be easier/more useful. But I'm just shooting in the dark welp
You mentioned that what you try to do seems too complex. Thats your first place to start.
Think about why it's too complex, then figure out a way to overcome that by splitting the task into more managable functions. Are those too complex? Repeat the process.
Books are a great resource if you're stuck, but reading other people's code is probably the fastest way to learn.
|
+ Show Spoiler +
#include <stdio.h>
int main()
{
int array[10][10];
int i;
int j;
int count;
for ( i; i<10; ++i )
{
for ( j = 0; j<10; ++j )
{
array[i][j] = count;
count++;
}
}
for ( i; i<10; ++i )
{
for ( j = 0; j<10; ++j )
{
printf( "%d", array[i][j] );
}
printf("\n");
}
}
I'm refreshing my C/C++ skills, and I don't understand why that doesn't print? Anyone know?
|
On November 13 2013 06:28 Arnstein wrote:+ Show Spoiler +
#include <stdio.h>
int main()
{
int array[10][10];
int i;
int j;
int count;
for ( i; i<10; ++i )
{
for ( j = 0; j<10; ++j )
{
array[i][j] = count;
count++;
}
}
for ( i; i<10; ++i )
{
for ( j = 0; j<10; ++j )
{
printf( "%d", array[i][j] );
}
printf("\n");
}
}
I'm refreshing my C/C++ skills, and I don't understand why that doesn't print? Anyone know?
i isn't initialized in both loops. Even assuming it gets defaulted to a value less than 10 in the first one, it enters the second one with value 10 so it never computes
|
Oh, of course! Added i = 0 and j = 0 between the loops now, and now it works. Thanks!
|
On November 13 2013 06:36 Arnstein wrote:
Oh, of course! Added i = 0 and j = 0 between the loops now, and now it works. Thanks!
j=0 between the outer fors (the i for's) won't acomplish what you want because j comes out of the first i iteration with value 10, and if you don't reset it, it stays 10 (which you do reset on the j=0; part of the for) and it would just print the first row.
Also dont forget to set i=0 before the first for.
You're welcome 
The j=0 next to the i=0 isn't really accomplishing anything, because atm it will assign it 0 again when it enters the loop. If you do get a habbit of setting the variables like that and happen to forget j=0 inside the i loop, it will only print the first row. Also, you're not setting i=0 before the first loop. Depending on compilers, systems and randomness, your program will not work because i will have a random value.
|
I did like this, and it works fine now:
+ Show Spoiler +
#include <stdio.h>
int main()
{
int array[10][10];
int i;
int j;
int count;
for ( i; i<10; ++i )
{
for ( j = 0; j<10; ++j )
{
array[i][j] = count;
count++;
}
}
i = 0;
j = 0;
for ( i; i<10; ++i )
{
for ( j = 0; j<10; ++j )
{
printf( "%d", array[i][j] );
printf( " " );
}
printf("\n");
}
}
|
|
|
|
|
|
EPT
