I have reviewed Is there such a thing as having too many private functions/methods? and I don't consider this a duplicate question.
I've been following some of the practices recommended in Robert Martin's "Clean Code" book, especially the ones that apply to the type of software I work with and the ones that make sense to me (I don't follow it as dogma).
One side effect I've noticed, however, is that the "clean" code I write, is more code than if I didn't follow some practices. The specific practices that lead to this are:
- Encapsulating conditionals
So instead of
if(contact.email != null && contact.emails.contains('@')
I could write a small method like this
private Boolean isEmailValid(String email){...}
- Replacing an inline comment with another private method, so that the method name describes itself rather than having an inline comment on top of it
- A class should only have one reason to change
And a few others. The point being, that what could be a method of 30 lines, ends up being a class, because of the tiny methods that replace comments and encapsulate conditionals, etc. When you realize you have so many methods, then it "makes sense" to put all the functionality into one class, when really it should've been a method.
I'm aware that any practice taken to the extreme can be harmful.
The concrete question I'm looking an answer for is:
Is this an acceptable byproduct of writing clean code? If so, what are some arguments I can use to justify the fact that more LOC have been written?
object-oriented-design clean-code
asked 1 hour ago
CRDevCRDev
1542
New contributor
CRDev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
I have reviewed Is there such a thing as having too many private functions/methods? and I don't consider this a duplicate question.
I've been following some of the practices recommended in Robert Martin's "Clean Code" book, especially the ones that apply to the type of software I work with and the ones that make sense to me (I don't follow it as dogma).
One side effect I've noticed, however, is that the "clean" code I write, is more code than if I didn't follow some practices. The specific practices that lead to this are:
- Encapsulating conditionals
So instead of
if(contact.email != null && contact.emails.contains('@')
I could write a small method like this
private Boolean isEmailValid(String email){...}
- Replacing an inline comment with another private method, so that the method name describes itself rather than having an inline comment on top of it
- A class should only have one reason to change
And a few others. The point being, that what could be a method of 30 lines, ends up being a class, because of the tiny methods that replace comments and encapsulate conditionals, etc. When you realize you have so many methods, then it "makes sense" to put all the functionality into one class, when really it should've been a method.
I'm aware that any practice taken to the extreme can be harmful.
The concrete question I'm looking an answer for is:
Is this an acceptable byproduct of writing clean code? If so, what are some arguments I can use to justify the fact that more LOC have been written?
object-oriented-design clean-code
asked 1 hour ago
CRDevCRDev
1542
New contributor
CRDev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
6
If your organization uses only LOC as a metric for your code bases, then justifying clean code there is hopeless to begin with.
– Kilian Foth
1 hour ago
It's not the only metric, but it's somewhat important because we are a very small team supporting a relatively large and undocumented code base (that we inherited), so some developers/managers see value in writing less code to get things done so that we have less code to maintain.
– CRDev
1 hour ago
I agree with your sentiment, although I would also say you shouldn't worry too much about it for the most part. I typically only to split off conditionals into private methods if there's a chance they'll be re-used.
– Graham
25 mins ago
1
If you believe that the code is not really clean now, then perhaps you should just encapsulate a little less to make it cleaner. No need to overthink this.
– Christian Hackl
18 mins ago
add a comment |
I have reviewed Is there such a thing as having too many private functions/methods? and I don't consider this a duplicate question.
I've been following some of the practices recommended in Robert Martin's "Clean Code" book, especially the ones that apply to the type of software I work with and the ones that make sense to me (I don't follow it as dogma).
One side effect I've noticed, however, is that the "clean" code I write, is more code than if I didn't follow some practices. The specific practices that lead to this are:
- Encapsulating conditionals
So instead of
if(contact.email != null && contact.emails.contains('@')
I could write a small method like this
private Boolean isEmailValid(String email){...}
- Replacing an inline comment with another private method, so that the method name describes itself rather than having an inline comment on top of it
- A class should only have one reason to change
And a few others. The point being, that what could be a method of 30 lines, ends up being a class, because of the tiny methods that replace comments and encapsulate conditionals, etc. When you realize you have so many methods, then it "makes sense" to put all the functionality into one class, when really it should've been a method.
I'm aware that any practice taken to the extreme can be harmful.
The concrete question I'm looking an answer for is:
Is this an acceptable byproduct of writing clean code? If so, what are some arguments I can use to justify the fact that more LOC have been written?
object-oriented-design clean-code
asked 1 hour ago
CRDevCRDev
1542
New contributor
CRDev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I have reviewed Is there such a thing as having too many private functions/methods? and I don't consider this a duplicate question.
I've been following some of the practices recommended in Robert Martin's "Clean Code" book, especially the ones that apply to the type of software I work with and the ones that make sense to me (I don't follow it as dogma).
One side effect I've noticed, however, is that the "clean" code I write, is more code than if I didn't follow some practices. The specific practices that lead to this are:
- Encapsulating conditionals
So instead of
if(contact.email != null && contact.emails.contains('@')
I could write a small method like this
private Boolean isEmailValid(String email){...}
- Replacing an inline comment with another private method, so that the method name describes itself rather than having an inline comment on top of it
- A class should only have one reason to change
And a few others. The point being, that what could be a method of 30 lines, ends up being a class, because of the tiny methods that replace comments and encapsulate conditionals, etc. When you realize you have so many methods, then it "makes sense" to put all the functionality into one class, when really it should've been a method.
I'm aware that any practice taken to the extreme can be harmful.
The concrete question I'm looking an answer for is:
Is this an acceptable byproduct of writing clean code? If so, what are some arguments I can use to justify the fact that more LOC have been written?
object-oriented-design clean-code
object-oriented-design clean-code
asked 1 hour ago
CRDevCRDev
1542
New contributor
CRDev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 1 hour ago
CRDevCRDev
1542
New contributor
CRDev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 1 hour ago
CRDevCRDev
1542
New contributor
CRDev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 1 hour ago
CRDevCRDev
1542
asked 1 hour ago
CRDevCRDev
1542
1542
New contributor
CRDev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
CRDev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
CRDev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
6
If your organization uses only LOC as a metric for your code bases, then justifying clean code there is hopeless to begin with.
– Kilian Foth
1 hour ago
It's not the only metric, but it's somewhat important because we are a very small team supporting a relatively large and undocumented code base (that we inherited), so some developers/managers see value in writing less code to get things done so that we have less code to maintain.
– CRDev
1 hour ago
I agree with your sentiment, although I would also say you shouldn't worry too much about it for the most part. I typically only to split off conditionals into private methods if there's a chance they'll be re-used.
– Graham
25 mins ago
1
If you believe that the code is not really clean now, then perhaps you should just encapsulate a little less to make it cleaner. No need to overthink this.
– Christian Hackl
18 mins ago
add a comment |
6
If your organization uses only LOC as a metric for your code bases, then justifying clean code there is hopeless to begin with.
– Kilian Foth
1 hour ago
It's not the only metric, but it's somewhat important because we are a very small team supporting a relatively large and undocumented code base (that we inherited), so some developers/managers see value in writing less code to get things done so that we have less code to maintain.
– CRDev
1 hour ago
I agree with your sentiment, although I would also say you shouldn't worry too much about it for the most part. I typically only to split off conditionals into private methods if there's a chance they'll be re-used.
– Graham
25 mins ago
1
If you believe that the code is not really clean now, then perhaps you should just encapsulate a little less to make it cleaner. No need to overthink this.
– Christian Hackl
18 mins ago
6
6
If your organization uses only LOC as a metric for your code bases, then justifying clean code there is hopeless to begin with.
– Kilian Foth
1 hour ago
If your organization uses only LOC as a metric for your code bases, then justifying clean code there is hopeless to begin with.
– Kilian Foth
1 hour ago
It's not the only metric, but it's somewhat important because we are a very small team supporting a relatively large and undocumented code base (that we inherited), so some developers/managers see value in writing less code to get things done so that we have less code to maintain.
– CRDev
1 hour ago
It's not the only metric, but it's somewhat important because we are a very small team supporting a relatively large and undocumented code base (that we inherited), so some developers/managers see value in writing less code to get things done so that we have less code to maintain.
– CRDev
1 hour ago
I agree with your sentiment, although I would also say you shouldn't worry too much about it for the most part. I typically only to split off conditionals into private methods if there's a chance they'll be re-used.
– Graham
25 mins ago
I agree with your sentiment, although I would also say you shouldn't worry too much about it for the most part. I typically only to split off conditionals into private methods if there's a chance they'll be re-used.
– Graham
25 mins ago
1
1
If you believe that the code is not really clean now, then perhaps you should just encapsulate a little less to make it cleaner. No need to overthink this.
– Christian Hackl
18 mins ago
If you believe that the code is not really clean now, then perhaps you should just encapsulate a little less to make it cleaner. No need to overthink this.
– Christian Hackl
18 mins ago
add a comment |
3 Answers
3
active
oldest
votes
Yes, it's an acceptable byproduct, and the justification is that it is now structured such that you don't have to read most of the code most of the time. Instead of reading a 30-line function every single time you are making a change, you are reading a 5-line function to get the overall flow, and maybe a couple of the helper functions if your change touches that area. If your new "extra" class is called EmailValidator and you know your problem isn't with email validation, you can skip reading it altogether.
It's also easier to reuse smaller pieces, which tends to reduce your line count for your overall program. An EmailValidator can be used all over the place. Some lines of code that do email validation but are scrunched together with database access code can't be reused.
answered 57 mins ago
Karl BielefeldtKarl Bielefeldt
120k29213412
add a comment |
... we are a very small team supporting a relatively large and undocumented code base (that we inherited), so some developers/managers see value in writing less code to get things done so that we have less code to maintain
These folk have correctly identified something: they want the code to be easier to maintain. Where they've gone wrong though is assuming that the less code there is, the easier it is to maintain.
For code to be easy to maintain, then it needs to be easy to change. By far the easiest way to achieve easy-to-change code is to have a full set of automated tests for it that will fail if your change is a breaking one. Tests are code, so writing those tests is going to swell your code base. And that is a good thing.
Secondly, in order to work out what needs changing, you code needs to be both easy to read and easy to reason about. Very terse code, shrunk in size just to keep the line count down is very unlikely to be easy to read. There's obviously a compromise to be struck as longer code will take longer to read. But if it's quicker to understand, then it's worth it. If it doesn't offer that benefit, then that verbosity stops being a benefit. But if longer code improves readability then again this is a good thing.
answered 53 mins ago
David ArnoDavid Arno
27.8k65390
2
"By far the easiest way to achieve easy-to-change code is to have a full set of automated tests for it that will fail if your change is a breaking one." This is simply not true. Tests require additional work for every behavioural change because the tests also need changing, this is by design and many would argue makes the change safer, but it also necessarily makes changes harder.
– Jack Aidley
36 mins ago
4
Sure, but the time lost in maintaining these tests is dwarfed by the time you would have lost diagnosing and fixing bugs that the tests prevent.
– MetaFight
34 mins ago
@JackAidley, having to change the tests along with the code might give the appearance of more work, but only if one ignores the hard-to-find bugs that changes to untested code will introduce and that often won't be found until after shipping. The latter merely offers the illusion of less work.
– David Arno
24 mins ago
1
I'd add to this answer that the "more code" version proposed also makes it easier to test because the logic is now isolated in a single location that you can write tests for, i.e. test theisEmailValidmethod itself rather than indirectly by testing unrelated code that happens to implement some tests for validity. And if you ever change the rules for validity...
– Colin Young
18 mins ago
@DavidArno: Perhaps, but you said "easy-to-change" code. Unit testing absolutely, unquestionably, does not make code easier to change. Your argument is that making the changes harder to make is worth it in terms of reducing number of bugs, but this is not the same thing as making it easier to change.
– Jack Aidley
7 mins ago
add a comment |
Bill Gates was famously attributed as saying, "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
I humbly agree with this sentiment. This is to not say that a program should strive for more or less lines of code, but that this isn't ultimately what counts to create a functioning and working program. It helps to remember that ultimately the reason behind adding extra lines of code is that it is theoretically more readable that way.
Disagreements can be had on whether a specific change is more or less readable, but I don't think you'd be wrong to make a change to your program because you think by doing so you're making it more readable. For instance making an isEmailValid could be thought to be superfluous and unnecessary, especially if it is being called exactly once by the class which defines it. However I would much rather see an isEmailValid in a condition than a string of ANDed conditions whereby I must determine what each individual condition checks and why it is being checked.
Where you get into trouble is when you create a isEmailValid method which has side effects or checks things other than the e-mail, because this is worse than simply writing it all out. It is worse because it is misleading and I may miss a bug because of it.
Though clearly you're not doing that in this case, so I would encourage you to continue as you're doing. You should always ask yourself if by making the change, it is easier to read, and if that is your case, then do it!
answered 54 mins ago
NeilNeil
20.2k3667
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "131"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
CRDev is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f388802%2fhow-do-you-justify-more-code-being-written-by-following-clean-code-practices%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Yes, it's an acceptable byproduct, and the justification is that it is now structured such that you don't have to read most of the code most of the time. Instead of reading a 30-line function every single time you are making a change, you are reading a 5-line function to get the overall flow, and maybe a couple of the helper functions if your change touches that area. If your new "extra" class is called EmailValidator and you know your problem isn't with email validation, you can skip reading it altogether.
It's also easier to reuse smaller pieces, which tends to reduce your line count for your overall program. An EmailValidator can be used all over the place. Some lines of code that do email validation but are scrunched together with database access code can't be reused.
answered 57 mins ago
Karl BielefeldtKarl Bielefeldt
120k29213412
add a comment |
Yes, it's an acceptable byproduct, and the justification is that it is now structured such that you don't have to read most of the code most of the time. Instead of reading a 30-line function every single time you are making a change, you are reading a 5-line function to get the overall flow, and maybe a couple of the helper functions if your change touches that area. If your new "extra" class is called EmailValidator and you know your problem isn't with email validation, you can skip reading it altogether.
It's also easier to reuse smaller pieces, which tends to reduce your line count for your overall program. An EmailValidator can be used all over the place. Some lines of code that do email validation but are scrunched together with database access code can't be reused.
answered 57 mins ago
Karl BielefeldtKarl Bielefeldt
120k29213412
add a comment |
Yes, it's an acceptable byproduct, and the justification is that it is now structured such that you don't have to read most of the code most of the time. Instead of reading a 30-line function every single time you are making a change, you are reading a 5-line function to get the overall flow, and maybe a couple of the helper functions if your change touches that area. If your new "extra" class is called EmailValidator and you know your problem isn't with email validation, you can skip reading it altogether.
It's also easier to reuse smaller pieces, which tends to reduce your line count for your overall program. An EmailValidator can be used all over the place. Some lines of code that do email validation but are scrunched together with database access code can't be reused.
answered 57 mins ago
Karl BielefeldtKarl Bielefeldt
120k29213412
Yes, it's an acceptable byproduct, and the justification is that it is now structured such that you don't have to read most of the code most of the time. Instead of reading a 30-line function every single time you are making a change, you are reading a 5-line function to get the overall flow, and maybe a couple of the helper functions if your change touches that area. If your new "extra" class is called EmailValidator and you know your problem isn't with email validation, you can skip reading it altogether.
It's also easier to reuse smaller pieces, which tends to reduce your line count for your overall program. An EmailValidator can be used all over the place. Some lines of code that do email validation but are scrunched together with database access code can't be reused.
answered 57 mins ago
Karl BielefeldtKarl Bielefeldt
120k29213412
answered 57 mins ago
Karl BielefeldtKarl Bielefeldt
120k29213412
answered 57 mins ago
Karl BielefeldtKarl Bielefeldt
120k29213412
answered 57 mins ago
Karl BielefeldtKarl Bielefeldt
120k29213412
120k29213412
add a comment |
add a comment |
... we are a very small team supporting a relatively large and undocumented code base (that we inherited), so some developers/managers see value in writing less code to get things done so that we have less code to maintain
These folk have correctly identified something: they want the code to be easier to maintain. Where they've gone wrong though is assuming that the less code there is, the easier it is to maintain.
For code to be easy to maintain, then it needs to be easy to change. By far the easiest way to achieve easy-to-change code is to have a full set of automated tests for it that will fail if your change is a breaking one. Tests are code, so writing those tests is going to swell your code base. And that is a good thing.
Secondly, in order to work out what needs changing, you code needs to be both easy to read and easy to reason about. Very terse code, shrunk in size just to keep the line count down is very unlikely to be easy to read. There's obviously a compromise to be struck as longer code will take longer to read. But if it's quicker to understand, then it's worth it. If it doesn't offer that benefit, then that verbosity stops being a benefit. But if longer code improves readability then again this is a good thing.
answered 53 mins ago
David ArnoDavid Arno
27.8k65390
2
"By far the easiest way to achieve easy-to-change code is to have a full set of automated tests for it that will fail if your change is a breaking one." This is simply not true. Tests require additional work for every behavioural change because the tests also need changing, this is by design and many would argue makes the change safer, but it also necessarily makes changes harder.
– Jack Aidley
36 mins ago
4
Sure, but the time lost in maintaining these tests is dwarfed by the time you would have lost diagnosing and fixing bugs that the tests prevent.
– MetaFight
34 mins ago
@JackAidley, having to change the tests along with the code might give the appearance of more work, but only if one ignores the hard-to-find bugs that changes to untested code will introduce and that often won't be found until after shipping. The latter merely offers the illusion of less work.
– David Arno
24 mins ago
1
I'd add to this answer that the "more code" version proposed also makes it easier to test because the logic is now isolated in a single location that you can write tests for, i.e. test theisEmailValidmethod itself rather than indirectly by testing unrelated code that happens to implement some tests for validity. And if you ever change the rules for validity...
– Colin Young
18 mins ago
@DavidArno: Perhaps, but you said "easy-to-change" code. Unit testing absolutely, unquestionably, does not make code easier to change. Your argument is that making the changes harder to make is worth it in terms of reducing number of bugs, but this is not the same thing as making it easier to change.
– Jack Aidley
7 mins ago
add a comment |
... we are a very small team supporting a relatively large and undocumented code base (that we inherited), so some developers/managers see value in writing less code to get things done so that we have less code to maintain
These folk have correctly identified something: they want the code to be easier to maintain. Where they've gone wrong though is assuming that the less code there is, the easier it is to maintain.
For code to be easy to maintain, then it needs to be easy to change. By far the easiest way to achieve easy-to-change code is to have a full set of automated tests for it that will fail if your change is a breaking one. Tests are code, so writing those tests is going to swell your code base. And that is a good thing.
Secondly, in order to work out what needs changing, you code needs to be both easy to read and easy to reason about. Very terse code, shrunk in size just to keep the line count down is very unlikely to be easy to read. There's obviously a compromise to be struck as longer code will take longer to read. But if it's quicker to understand, then it's worth it. If it doesn't offer that benefit, then that verbosity stops being a benefit. But if longer code improves readability then again this is a good thing.
answered 53 mins ago
David ArnoDavid Arno
27.8k65390
2
"By far the easiest way to achieve easy-to-change code is to have a full set of automated tests for it that will fail if your change is a breaking one." This is simply not true. Tests require additional work for every behavioural change because the tests also need changing, this is by design and many would argue makes the change safer, but it also necessarily makes changes harder.
– Jack Aidley
36 mins ago
4
Sure, but the time lost in maintaining these tests is dwarfed by the time you would have lost diagnosing and fixing bugs that the tests prevent.
– MetaFight
34 mins ago
@JackAidley, having to change the tests along with the code might give the appearance of more work, but only if one ignores the hard-to-find bugs that changes to untested code will introduce and that often won't be found until after shipping. The latter merely offers the illusion of less work.
– David Arno
24 mins ago
1
I'd add to this answer that the "more code" version proposed also makes it easier to test because the logic is now isolated in a single location that you can write tests for, i.e. test theisEmailValidmethod itself rather than indirectly by testing unrelated code that happens to implement some tests for validity. And if you ever change the rules for validity...
– Colin Young
18 mins ago
@DavidArno: Perhaps, but you said "easy-to-change" code. Unit testing absolutely, unquestionably, does not make code easier to change. Your argument is that making the changes harder to make is worth it in terms of reducing number of bugs, but this is not the same thing as making it easier to change.
– Jack Aidley
7 mins ago
add a comment |
... we are a very small team supporting a relatively large and undocumented code base (that we inherited), so some developers/managers see value in writing less code to get things done so that we have less code to maintain
These folk have correctly identified something: they want the code to be easier to maintain. Where they've gone wrong though is assuming that the less code there is, the easier it is to maintain.
For code to be easy to maintain, then it needs to be easy to change. By far the easiest way to achieve easy-to-change code is to have a full set of automated tests for it that will fail if your change is a breaking one. Tests are code, so writing those tests is going to swell your code base. And that is a good thing.
Secondly, in order to work out what needs changing, you code needs to be both easy to read and easy to reason about. Very terse code, shrunk in size just to keep the line count down is very unlikely to be easy to read. There's obviously a compromise to be struck as longer code will take longer to read. But if it's quicker to understand, then it's worth it. If it doesn't offer that benefit, then that verbosity stops being a benefit. But if longer code improves readability then again this is a good thing.
answered 53 mins ago
David ArnoDavid Arno
27.8k65390
... we are a very small team supporting a relatively large and undocumented code base (that we inherited), so some developers/managers see value in writing less code to get things done so that we have less code to maintain
These folk have correctly identified something: they want the code to be easier to maintain. Where they've gone wrong though is assuming that the less code there is, the easier it is to maintain.
For code to be easy to maintain, then it needs to be easy to change. By far the easiest way to achieve easy-to-change code is to have a full set of automated tests for it that will fail if your change is a breaking one. Tests are code, so writing those tests is going to swell your code base. And that is a good thing.
Secondly, in order to work out what needs changing, you code needs to be both easy to read and easy to reason about. Very terse code, shrunk in size just to keep the line count down is very unlikely to be easy to read. There's obviously a compromise to be struck as longer code will take longer to read. But if it's quicker to understand, then it's worth it. If it doesn't offer that benefit, then that verbosity stops being a benefit. But if longer code improves readability then again this is a good thing.
answered 53 mins ago
David ArnoDavid Arno
27.8k65390
answered 53 mins ago
David ArnoDavid Arno
27.8k65390
answered 53 mins ago
David ArnoDavid Arno
27.8k65390
answered 53 mins ago
David ArnoDavid Arno
27.8k65390
27.8k65390
2
"By far the easiest way to achieve easy-to-change code is to have a full set of automated tests for it that will fail if your change is a breaking one." This is simply not true. Tests require additional work for every behavioural change because the tests also need changing, this is by design and many would argue makes the change safer, but it also necessarily makes changes harder.
– Jack Aidley
36 mins ago
4
Sure, but the time lost in maintaining these tests is dwarfed by the time you would have lost diagnosing and fixing bugs that the tests prevent.
– MetaFight
34 mins ago
@JackAidley, having to change the tests along with the code might give the appearance of more work, but only if one ignores the hard-to-find bugs that changes to untested code will introduce and that often won't be found until after shipping. The latter merely offers the illusion of less work.
– David Arno
24 mins ago
1
I'd add to this answer that the "more code" version proposed also makes it easier to test because the logic is now isolated in a single location that you can write tests for, i.e. test theisEmailValidmethod itself rather than indirectly by testing unrelated code that happens to implement some tests for validity. And if you ever change the rules for validity...
– Colin Young
18 mins ago
@DavidArno: Perhaps, but you said "easy-to-change" code. Unit testing absolutely, unquestionably, does not make code easier to change. Your argument is that making the changes harder to make is worth it in terms of reducing number of bugs, but this is not the same thing as making it easier to change.
– Jack Aidley
7 mins ago
add a comment |
2
"By far the easiest way to achieve easy-to-change code is to have a full set of automated tests for it that will fail if your change is a breaking one." This is simply not true. Tests require additional work for every behavioural change because the tests also need changing, this is by design and many would argue makes the change safer, but it also necessarily makes changes harder.
– Jack Aidley
36 mins ago
4
Sure, but the time lost in maintaining these tests is dwarfed by the time you would have lost diagnosing and fixing bugs that the tests prevent.
– MetaFight
34 mins ago
@JackAidley, having to change the tests along with the code might give the appearance of more work, but only if one ignores the hard-to-find bugs that changes to untested code will introduce and that often won't be found until after shipping. The latter merely offers the illusion of less work.
– David Arno
24 mins ago
1
I'd add to this answer that the "more code" version proposed also makes it easier to test because the logic is now isolated in a single location that you can write tests for, i.e. test theisEmailValidmethod itself rather than indirectly by testing unrelated code that happens to implement some tests for validity. And if you ever change the rules for validity...
– Colin Young
18 mins ago
@DavidArno: Perhaps, but you said "easy-to-change" code. Unit testing absolutely, unquestionably, does not make code easier to change. Your argument is that making the changes harder to make is worth it in terms of reducing number of bugs, but this is not the same thing as making it easier to change.
– Jack Aidley
7 mins ago
2
2
"By far the easiest way to achieve easy-to-change code is to have a full set of automated tests for it that will fail if your change is a breaking one." This is simply not true. Tests require additional work for every behavioural change because the tests also need changing, this is by design and many would argue makes the change safer, but it also necessarily makes changes harder.
– Jack Aidley
36 mins ago
"By far the easiest way to achieve easy-to-change code is to have a full set of automated tests for it that will fail if your change is a breaking one." This is simply not true. Tests require additional work for every behavioural change because the tests also need changing, this is by design and many would argue makes the change safer, but it also necessarily makes changes harder.
– Jack Aidley
36 mins ago
4
4
Sure, but the time lost in maintaining these tests is dwarfed by the time you would have lost diagnosing and fixing bugs that the tests prevent.
– MetaFight
34 mins ago
Sure, but the time lost in maintaining these tests is dwarfed by the time you would have lost diagnosing and fixing bugs that the tests prevent.
– MetaFight
34 mins ago
@JackAidley, having to change the tests along with the code might give the appearance of more work, but only if one ignores the hard-to-find bugs that changes to untested code will introduce and that often won't be found until after shipping. The latter merely offers the illusion of less work.
– David Arno
24 mins ago
@JackAidley, having to change the tests along with the code might give the appearance of more work, but only if one ignores the hard-to-find bugs that changes to untested code will introduce and that often won't be found until after shipping. The latter merely offers the illusion of less work.
– David Arno
24 mins ago
1
1
I'd add to this answer that the "more code" version proposed also makes it easier to test because the logic is now isolated in a single location that you can write tests for, i.e. test the
isEmailValid method itself rather than indirectly by testing unrelated code that happens to implement some tests for validity. And if you ever change the rules for validity...– Colin Young
18 mins ago
I'd add to this answer that the "more code" version proposed also makes it easier to test because the logic is now isolated in a single location that you can write tests for, i.e. test the
isEmailValid method itself rather than indirectly by testing unrelated code that happens to implement some tests for validity. And if you ever change the rules for validity...– Colin Young
18 mins ago
@DavidArno: Perhaps, but you said "easy-to-change" code. Unit testing absolutely, unquestionably, does not make code easier to change. Your argument is that making the changes harder to make is worth it in terms of reducing number of bugs, but this is not the same thing as making it easier to change.
– Jack Aidley
7 mins ago
@DavidArno: Perhaps, but you said "easy-to-change" code. Unit testing absolutely, unquestionably, does not make code easier to change. Your argument is that making the changes harder to make is worth it in terms of reducing number of bugs, but this is not the same thing as making it easier to change.
– Jack Aidley
7 mins ago
add a comment |
Bill Gates was famously attributed as saying, "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
I humbly agree with this sentiment. This is to not say that a program should strive for more or less lines of code, but that this isn't ultimately what counts to create a functioning and working program. It helps to remember that ultimately the reason behind adding extra lines of code is that it is theoretically more readable that way.
Disagreements can be had on whether a specific change is more or less readable, but I don't think you'd be wrong to make a change to your program because you think by doing so you're making it more readable. For instance making an isEmailValid could be thought to be superfluous and unnecessary, especially if it is being called exactly once by the class which defines it. However I would much rather see an isEmailValid in a condition than a string of ANDed conditions whereby I must determine what each individual condition checks and why it is being checked.
Where you get into trouble is when you create a isEmailValid method which has side effects or checks things other than the e-mail, because this is worse than simply writing it all out. It is worse because it is misleading and I may miss a bug because of it.
Though clearly you're not doing that in this case, so I would encourage you to continue as you're doing. You should always ask yourself if by making the change, it is easier to read, and if that is your case, then do it!
answered 54 mins ago
NeilNeil
20.2k3667
add a comment |
Bill Gates was famously attributed as saying, "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
I humbly agree with this sentiment. This is to not say that a program should strive for more or less lines of code, but that this isn't ultimately what counts to create a functioning and working program. It helps to remember that ultimately the reason behind adding extra lines of code is that it is theoretically more readable that way.
Disagreements can be had on whether a specific change is more or less readable, but I don't think you'd be wrong to make a change to your program because you think by doing so you're making it more readable. For instance making an isEmailValid could be thought to be superfluous and unnecessary, especially if it is being called exactly once by the class which defines it. However I would much rather see an isEmailValid in a condition than a string of ANDed conditions whereby I must determine what each individual condition checks and why it is being checked.
Where you get into trouble is when you create a isEmailValid method which has side effects or checks things other than the e-mail, because this is worse than simply writing it all out. It is worse because it is misleading and I may miss a bug because of it.
Though clearly you're not doing that in this case, so I would encourage you to continue as you're doing. You should always ask yourself if by making the change, it is easier to read, and if that is your case, then do it!
answered 54 mins ago
NeilNeil
20.2k3667
add a comment |
Bill Gates was famously attributed as saying, "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
I humbly agree with this sentiment. This is to not say that a program should strive for more or less lines of code, but that this isn't ultimately what counts to create a functioning and working program. It helps to remember that ultimately the reason behind adding extra lines of code is that it is theoretically more readable that way.
Disagreements can be had on whether a specific change is more or less readable, but I don't think you'd be wrong to make a change to your program because you think by doing so you're making it more readable. For instance making an isEmailValid could be thought to be superfluous and unnecessary, especially if it is being called exactly once by the class which defines it. However I would much rather see an isEmailValid in a condition than a string of ANDed conditions whereby I must determine what each individual condition checks and why it is being checked.
Where you get into trouble is when you create a isEmailValid method which has side effects or checks things other than the e-mail, because this is worse than simply writing it all out. It is worse because it is misleading and I may miss a bug because of it.
Though clearly you're not doing that in this case, so I would encourage you to continue as you're doing. You should always ask yourself if by making the change, it is easier to read, and if that is your case, then do it!
answered 54 mins ago
NeilNeil
20.2k3667
Bill Gates was famously attributed as saying, "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
I humbly agree with this sentiment. This is to not say that a program should strive for more or less lines of code, but that this isn't ultimately what counts to create a functioning and working program. It helps to remember that ultimately the reason behind adding extra lines of code is that it is theoretically more readable that way.
Disagreements can be had on whether a specific change is more or less readable, but I don't think you'd be wrong to make a change to your program because you think by doing so you're making it more readable. For instance making an isEmailValid could be thought to be superfluous and unnecessary, especially if it is being called exactly once by the class which defines it. However I would much rather see an isEmailValid in a condition than a string of ANDed conditions whereby I must determine what each individual condition checks and why it is being checked.
Where you get into trouble is when you create a isEmailValid method which has side effects or checks things other than the e-mail, because this is worse than simply writing it all out. It is worse because it is misleading and I may miss a bug because of it.
Though clearly you're not doing that in this case, so I would encourage you to continue as you're doing. You should always ask yourself if by making the change, it is easier to read, and if that is your case, then do it!
answered 54 mins ago
NeilNeil
20.2k3667
answered 54 mins ago
NeilNeil
20.2k3667
answered 54 mins ago
NeilNeil
20.2k3667
answered 54 mins ago
NeilNeil
20.2k3667
20.2k3667
add a comment |
add a comment |
CRDev is a new contributor. Be nice, and check out our Code of Conduct.
CRDev is a new contributor. Be nice, and check out our Code of Conduct.
CRDev is a new contributor. Be nice, and check out our Code of Conduct.
CRDev is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Software Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f388802%2fhow-do-you-justify-more-code-being-written-by-following-clean-code-practices%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
6
If your organization uses only LOC as a metric for your code bases, then justifying clean code there is hopeless to begin with.
– Kilian Foth
1 hour ago
It's not the only metric, but it's somewhat important because we are a very small team supporting a relatively large and undocumented code base (that we inherited), so some developers/managers see value in writing less code to get things done so that we have less code to maintain.
– CRDev
1 hour ago
I agree with your sentiment, although I would also say you shouldn't worry too much about it for the most part. I typically only to split off conditionals into private methods if there's a chance they'll be re-used.
– Graham
25 mins ago
1
If you believe that the code is not really clean now, then perhaps you should just encapsulate a little less to make it cleaner. No need to overthink this.
– Christian Hackl
18 mins ago