Skip to main content
deleted 26 characters in body
Source Link
JacquesB
  • 62.4k
  • 21
  • 137
  • 190

If you are in doubt, it probably is too clever! The second example introduces accidental complexity with expressions like foo ? parseFoo(foo) : x => x, and overall the code is more complex which means it is harder to follow.

The purported benefit, that you can test the chunks individually, could be achieved in a simpler way by just breaking into individual functions. And in the second example you couple the otherwise separate iterations, so you actually get less isolation.

Whatever your feelings about functional style in general, this is clearly an example where it makes the code more complex.

I find a bit of a warning signal in that you associate simple and straightforward code with "novice developers". This is a dangerous mentality. In my experience it is the opposite: Novice developers are prone to overly complex and clever code, because it requires a more experience to be able to see the simplest and clearest solution.

The advice against "clever code" is not really about whether or not the code uses advanced concepts which a novice might not understand. Rather it is about writing code which is more complex or convoluted than necessary, in order to "show off". This makes the code harder to follow for everybody, novices and experts alike, and probably also for yourself some months down the line.

If you are in doubt, it probably is too clever! The second example introduces accidental complexity with expressions like foo ? parseFoo(foo) : x => x, and overall the code is more complex which means it is harder to follow.

The purported benefit, that you can test the chunks individually, could be achieved in a simpler way by just breaking into individual functions. And in the second example you couple the otherwise separate iterations, so you actually get less isolation.

Whatever your feelings about functional style in general, this is clearly an example where it makes the code more complex.

I find a bit of a warning signal in that you associate simple and straightforward code with "novice developers". This is a dangerous mentality. In my experience it is the opposite: Novice developers are prone to overly complex and clever code, because it requires a more experience to be able to see the simplest and clearest solution.

The advice against "clever code" is not really about whether or not the code uses advanced concepts which a novice might not understand. Rather it is about writing code which is more complex or convoluted than necessary, in order to "show off". This makes the code harder to follow for everybody, novices and experts alike, and probably also for yourself some months down the line.

If you are in doubt, it probably is too clever! The second example introduces accidental complexity with expressions like foo ? parseFoo(foo) : x => x, and overall the code is more complex which means it is harder to follow.

The purported benefit, that you can test the chunks individually, could be achieved in a simpler way by just breaking into individual functions. And in the second example you couple the otherwise separate iterations, so you actually get less isolation.

Whatever your feelings about functional style in general, this is clearly an example where it makes the code more complex.

I find a bit of a warning signal in that you associate simple and straightforward code with "novice developers". This is a dangerous mentality. In my experience it is the opposite: Novice developers are prone to overly complex and clever code, because it requires more experience to be able to see the simplest and clearest solution.

The advice against "clever code" is not really about whether or not the code uses advanced concepts which a novice might not understand. Rather it is about writing code which is more complex or convoluted than necessary. This makes the code harder to follow for everybody, novices and experts alike, and probably also for yourself some months down the line.

added 389 characters in body
Source Link
JacquesB
  • 62.4k
  • 21
  • 137
  • 190

If you are in doubt, it probably is too clever! The second example introduces accidental complexity with expressions like foo ? parseFoo(foo) : x => x, and overall the code is more complex which means it is harder to follow.

The purported benefit, that you can test the chunks individually, could be achieved in a simpler way by just breaking into individual functions. And in the second example you couple the otherwise separate iterations, so you actually get less isolation.

Whatever your feelings about functional style in general, this is clearly an example where it makes the code more complex.

I find a bit of a warning signal in that you associate simple and straightforward code with "novice developers". This is a dangerous mentality. In my experience it is the opposite: Novice developers are prone to overly complex and clever code, because it requires a more experience to be able to see the simplest and clearest solution.

The advice against "clever code" is not really about whether or not the code uses advanced concepts which a novice might not understand. Rather it is about writing code which is more complex or convoluted than necessary, in order to "show off". This makes the code harder to follow for everybody, novices and experts alike, and probably also for yourself some months down the line.

If you are in doubt, it probably is too clever! The second example introduces accidental complexity with expressions like foo ? parseFoo(foo) : x => x, and overall the code is more complex which means it is harder to follow.

The purported benefit, that you can test the chunks individually, could be achieved in a simpler way by just breaking into individual functions. And in the second example you couple the otherwise separate iterations, so you actually get less isolation.

Whatever your feelings about functional style in general, this is clearly an example where it makes the code more complex.

I find a bit of a warning signal in that you associate simple and straightforward code with "novice developers". This is a dangerous mentality. In my experience it is the opposite: Novice developers are prone to overly complex and clever code, because it requires a more experience to be able to see the simplest and clearest solution.

If you are in doubt, it probably is too clever! The second example introduces accidental complexity with expressions like foo ? parseFoo(foo) : x => x, and overall the code is more complex which means it is harder to follow.

The purported benefit, that you can test the chunks individually, could be achieved in a simpler way by just breaking into individual functions. And in the second example you couple the otherwise separate iterations, so you actually get less isolation.

Whatever your feelings about functional style in general, this is clearly an example where it makes the code more complex.

I find a bit of a warning signal in that you associate simple and straightforward code with "novice developers". This is a dangerous mentality. In my experience it is the opposite: Novice developers are prone to overly complex and clever code, because it requires a more experience to be able to see the simplest and clearest solution.

The advice against "clever code" is not really about whether or not the code uses advanced concepts which a novice might not understand. Rather it is about writing code which is more complex or convoluted than necessary, in order to "show off". This makes the code harder to follow for everybody, novices and experts alike, and probably also for yourself some months down the line.

Source Link
JacquesB
  • 62.4k
  • 21
  • 137
  • 190

If you are in doubt, it probably is too clever! The second example introduces accidental complexity with expressions like foo ? parseFoo(foo) : x => x, and overall the code is more complex which means it is harder to follow.

The purported benefit, that you can test the chunks individually, could be achieved in a simpler way by just breaking into individual functions. And in the second example you couple the otherwise separate iterations, so you actually get less isolation.

Whatever your feelings about functional style in general, this is clearly an example where it makes the code more complex.

I find a bit of a warning signal in that you associate simple and straightforward code with "novice developers". This is a dangerous mentality. In my experience it is the opposite: Novice developers are prone to overly complex and clever code, because it requires a more experience to be able to see the simplest and clearest solution.