Split string in half and change case accordingly











up vote
11
down vote

favorite












I found the following challenge online:




Create a function that takes a string and returns that string with the first half lowercased and the last half uppercased.



eg: foobar == fooBAR



If it is an odd number then 'round' it up to find which letters to uppercase.




That sounded easy enough but I found the last requirement a little tricky. Eventually this is what I came up with:





def sillycase(silly):
length=len(silly)
firstHalf = silly[:length / 2 + (length % 2)].lower()
secondHalf = silly[length / 2 + (length % 2):].upper()
return firstHalf + secondHalf


but that seems repetitive and inefficient.



What could I have done to make it slicker, without sacrificing readability? I was actually a little surprised python didn't have a built in method to split a string in half.










share|improve this question
























  • Regarding the last requirement: What about the ceil function?
    – Nobody
    Apr 15 '15 at 14:12















up vote
11
down vote

favorite












I found the following challenge online:




Create a function that takes a string and returns that string with the first half lowercased and the last half uppercased.



eg: foobar == fooBAR



If it is an odd number then 'round' it up to find which letters to uppercase.




That sounded easy enough but I found the last requirement a little tricky. Eventually this is what I came up with:





def sillycase(silly):
length=len(silly)
firstHalf = silly[:length / 2 + (length % 2)].lower()
secondHalf = silly[length / 2 + (length % 2):].upper()
return firstHalf + secondHalf


but that seems repetitive and inefficient.



What could I have done to make it slicker, without sacrificing readability? I was actually a little surprised python didn't have a built in method to split a string in half.










share|improve this question
























  • Regarding the last requirement: What about the ceil function?
    – Nobody
    Apr 15 '15 at 14:12













up vote
11
down vote

favorite









up vote
11
down vote

favorite











I found the following challenge online:




Create a function that takes a string and returns that string with the first half lowercased and the last half uppercased.



eg: foobar == fooBAR



If it is an odd number then 'round' it up to find which letters to uppercase.




That sounded easy enough but I found the last requirement a little tricky. Eventually this is what I came up with:





def sillycase(silly):
length=len(silly)
firstHalf = silly[:length / 2 + (length % 2)].lower()
secondHalf = silly[length / 2 + (length % 2):].upper()
return firstHalf + secondHalf


but that seems repetitive and inefficient.



What could I have done to make it slicker, without sacrificing readability? I was actually a little surprised python didn't have a built in method to split a string in half.










share|improve this question















I found the following challenge online:




Create a function that takes a string and returns that string with the first half lowercased and the last half uppercased.



eg: foobar == fooBAR



If it is an odd number then 'round' it up to find which letters to uppercase.




That sounded easy enough but I found the last requirement a little tricky. Eventually this is what I came up with:





def sillycase(silly):
length=len(silly)
firstHalf = silly[:length / 2 + (length % 2)].lower()
secondHalf = silly[length / 2 + (length % 2):].upper()
return firstHalf + secondHalf


but that seems repetitive and inefficient.



What could I have done to make it slicker, without sacrificing readability? I was actually a little surprised python didn't have a built in method to split a string in half.







python strings programming-challenge






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 15 '15 at 5:36









200_success

127k15149412




127k15149412










asked Apr 15 '15 at 3:48









Seth

158312




158312












  • Regarding the last requirement: What about the ceil function?
    – Nobody
    Apr 15 '15 at 14:12


















  • Regarding the last requirement: What about the ceil function?
    – Nobody
    Apr 15 '15 at 14:12
















Regarding the last requirement: What about the ceil function?
– Nobody
Apr 15 '15 at 14:12




Regarding the last requirement: What about the ceil function?
– Nobody
Apr 15 '15 at 14:12










2 Answers
2






active

oldest

votes

















up vote
15
down vote



accepted










Midpoint math is often a pain in the whatnot, but a real trick is to add 1 to the length before halving it. Additionally, instead of repeating the math multiple times, you can do it just once.



def sillycase(silly):
mid=(len(silly) + 1) / 2
firstHalf = silly[:mid].lower()
secondHalf = silly[mid:].upper()
return firstHalf + secondHalf


At that point, it becomes small enough to not need the temp variables:



def sillycase(silly):
mid = (len(silly) + 1) // 2
return silly[:mid].lower() + silly[mid:].upper()

print (sillycase("hello"))
print (sillycase("helloa"))
print (sillycase("helloab"))


http://ideone.com/CqUdl5



Note the use of the integer divide which is suitable for both python 2.x and 3.






share|improve this answer





















  • It might be/certainly is over expressive but i'd be tempted to return "" on mid==0 to be explicit.
    – Aiden Bell
    Apr 15 '15 at 21:11












  • @AidenBell - it certainly could be more efficient for sillily small sillies, but the simple mid==0would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meant len(silly) == 0?
    – rolfl
    Apr 15 '15 at 21:15










  • Yes, of course that would be more correct. How silly of me ;)
    – Aiden Bell
    Apr 15 '15 at 21:27






  • 1




    I'm just mentioning it for completeness, but personally I find - (-x // y) should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.
    – Veedrac
    Apr 21 '15 at 7:36


















up vote
0
down vote













If it were me I'd just go for brevity and ensure the function name is expressive:



def silly_case(input_string):
return "".join([char.lower() if index < (len(input_string) + 1)/ 2 else char.upper() for index, char in enumerate(input_string)])


EDIT:



I've gotten lots of criticism for my answer for stuffing things to one line, but I'm still a fan of list comprehensions, and I find it completely intuitive. Based on the feedback, here's how I would implement this function:



def silly_case(input_string):
pivot_index = (len(input_string) + 1) / 2
char_list = [char.lower() if index < pivot_index else char.upper() for index, char in enumerate(input_string)]
return "".join(char_list)





share|improve this answer



















  • 2




    Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
    – Aiden Bell
    Apr 15 '15 at 21:09










  • If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change (len(input_string) + 1)/ 2 to pivot_index and perhaps move "".join(string_as_list) to its own line but otherwise this seems like a straightforward list comprehension to me.
    – Scott Lobdell
    Apr 16 '15 at 19:40












  • "If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
    – Aiden Bell
    Apr 16 '15 at 21:02








  • 1




    In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
    – Aiden Bell
    Apr 16 '15 at 21:04








  • 1




    @ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
    – Aiden Bell
    Apr 18 '15 at 17:55











Your Answer





StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
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',
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
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f86933%2fsplit-string-in-half-and-change-case-accordingly%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
15
down vote



accepted










Midpoint math is often a pain in the whatnot, but a real trick is to add 1 to the length before halving it. Additionally, instead of repeating the math multiple times, you can do it just once.



def sillycase(silly):
mid=(len(silly) + 1) / 2
firstHalf = silly[:mid].lower()
secondHalf = silly[mid:].upper()
return firstHalf + secondHalf


At that point, it becomes small enough to not need the temp variables:



def sillycase(silly):
mid = (len(silly) + 1) // 2
return silly[:mid].lower() + silly[mid:].upper()

print (sillycase("hello"))
print (sillycase("helloa"))
print (sillycase("helloab"))


http://ideone.com/CqUdl5



Note the use of the integer divide which is suitable for both python 2.x and 3.






share|improve this answer





















  • It might be/certainly is over expressive but i'd be tempted to return "" on mid==0 to be explicit.
    – Aiden Bell
    Apr 15 '15 at 21:11












  • @AidenBell - it certainly could be more efficient for sillily small sillies, but the simple mid==0would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meant len(silly) == 0?
    – rolfl
    Apr 15 '15 at 21:15










  • Yes, of course that would be more correct. How silly of me ;)
    – Aiden Bell
    Apr 15 '15 at 21:27






  • 1




    I'm just mentioning it for completeness, but personally I find - (-x // y) should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.
    – Veedrac
    Apr 21 '15 at 7:36















up vote
15
down vote



accepted










Midpoint math is often a pain in the whatnot, but a real trick is to add 1 to the length before halving it. Additionally, instead of repeating the math multiple times, you can do it just once.



def sillycase(silly):
mid=(len(silly) + 1) / 2
firstHalf = silly[:mid].lower()
secondHalf = silly[mid:].upper()
return firstHalf + secondHalf


At that point, it becomes small enough to not need the temp variables:



def sillycase(silly):
mid = (len(silly) + 1) // 2
return silly[:mid].lower() + silly[mid:].upper()

print (sillycase("hello"))
print (sillycase("helloa"))
print (sillycase("helloab"))


http://ideone.com/CqUdl5



Note the use of the integer divide which is suitable for both python 2.x and 3.






share|improve this answer





















  • It might be/certainly is over expressive but i'd be tempted to return "" on mid==0 to be explicit.
    – Aiden Bell
    Apr 15 '15 at 21:11












  • @AidenBell - it certainly could be more efficient for sillily small sillies, but the simple mid==0would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meant len(silly) == 0?
    – rolfl
    Apr 15 '15 at 21:15










  • Yes, of course that would be more correct. How silly of me ;)
    – Aiden Bell
    Apr 15 '15 at 21:27






  • 1




    I'm just mentioning it for completeness, but personally I find - (-x // y) should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.
    – Veedrac
    Apr 21 '15 at 7:36













up vote
15
down vote



accepted







up vote
15
down vote



accepted






Midpoint math is often a pain in the whatnot, but a real trick is to add 1 to the length before halving it. Additionally, instead of repeating the math multiple times, you can do it just once.



def sillycase(silly):
mid=(len(silly) + 1) / 2
firstHalf = silly[:mid].lower()
secondHalf = silly[mid:].upper()
return firstHalf + secondHalf


At that point, it becomes small enough to not need the temp variables:



def sillycase(silly):
mid = (len(silly) + 1) // 2
return silly[:mid].lower() + silly[mid:].upper()

print (sillycase("hello"))
print (sillycase("helloa"))
print (sillycase("helloab"))


http://ideone.com/CqUdl5



Note the use of the integer divide which is suitable for both python 2.x and 3.






share|improve this answer












Midpoint math is often a pain in the whatnot, but a real trick is to add 1 to the length before halving it. Additionally, instead of repeating the math multiple times, you can do it just once.



def sillycase(silly):
mid=(len(silly) + 1) / 2
firstHalf = silly[:mid].lower()
secondHalf = silly[mid:].upper()
return firstHalf + secondHalf


At that point, it becomes small enough to not need the temp variables:



def sillycase(silly):
mid = (len(silly) + 1) // 2
return silly[:mid].lower() + silly[mid:].upper()

print (sillycase("hello"))
print (sillycase("helloa"))
print (sillycase("helloab"))


http://ideone.com/CqUdl5



Note the use of the integer divide which is suitable for both python 2.x and 3.







share|improve this answer












share|improve this answer



share|improve this answer










answered Apr 15 '15 at 4:06









rolfl

90.6k13190394




90.6k13190394












  • It might be/certainly is over expressive but i'd be tempted to return "" on mid==0 to be explicit.
    – Aiden Bell
    Apr 15 '15 at 21:11












  • @AidenBell - it certainly could be more efficient for sillily small sillies, but the simple mid==0would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meant len(silly) == 0?
    – rolfl
    Apr 15 '15 at 21:15










  • Yes, of course that would be more correct. How silly of me ;)
    – Aiden Bell
    Apr 15 '15 at 21:27






  • 1




    I'm just mentioning it for completeness, but personally I find - (-x // y) should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.
    – Veedrac
    Apr 21 '15 at 7:36


















  • It might be/certainly is over expressive but i'd be tempted to return "" on mid==0 to be explicit.
    – Aiden Bell
    Apr 15 '15 at 21:11












  • @AidenBell - it certainly could be more efficient for sillily small sillies, but the simple mid==0would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meant len(silly) == 0?
    – rolfl
    Apr 15 '15 at 21:15










  • Yes, of course that would be more correct. How silly of me ;)
    – Aiden Bell
    Apr 15 '15 at 21:27






  • 1




    I'm just mentioning it for completeness, but personally I find - (-x // y) should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.
    – Veedrac
    Apr 21 '15 at 7:36
















It might be/certainly is over expressive but i'd be tempted to return "" on mid==0 to be explicit.
– Aiden Bell
Apr 15 '15 at 21:11






It might be/certainly is over expressive but i'd be tempted to return "" on mid==0 to be explicit.
– Aiden Bell
Apr 15 '15 at 21:11














@AidenBell - it certainly could be more efficient for sillily small sillies, but the simple mid==0would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meant len(silly) == 0?
– rolfl
Apr 15 '15 at 21:15




@AidenBell - it certainly could be more efficient for sillily small sillies, but the simple mid==0would fail to process 1-letter values, like.... "i"... where mid would be 0, but the caps would still need to happen. Perhaps you meant len(silly) == 0?
– rolfl
Apr 15 '15 at 21:15












Yes, of course that would be more correct. How silly of me ;)
– Aiden Bell
Apr 15 '15 at 21:27




Yes, of course that would be more correct. How silly of me ;)
– Aiden Bell
Apr 15 '15 at 21:27




1




1




I'm just mentioning it for completeness, but personally I find - (-x // y) should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.
– Veedrac
Apr 21 '15 at 7:36




I'm just mentioning it for completeness, but personally I find - (-x // y) should be the canonical code for "round-up" division: it's lossless, works on Python 3, doesn't involve constants, always works for negative divisors and even works for floating point.
– Veedrac
Apr 21 '15 at 7:36












up vote
0
down vote













If it were me I'd just go for brevity and ensure the function name is expressive:



def silly_case(input_string):
return "".join([char.lower() if index < (len(input_string) + 1)/ 2 else char.upper() for index, char in enumerate(input_string)])


EDIT:



I've gotten lots of criticism for my answer for stuffing things to one line, but I'm still a fan of list comprehensions, and I find it completely intuitive. Based on the feedback, here's how I would implement this function:



def silly_case(input_string):
pivot_index = (len(input_string) + 1) / 2
char_list = [char.lower() if index < pivot_index else char.upper() for index, char in enumerate(input_string)]
return "".join(char_list)





share|improve this answer



















  • 2




    Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
    – Aiden Bell
    Apr 15 '15 at 21:09










  • If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change (len(input_string) + 1)/ 2 to pivot_index and perhaps move "".join(string_as_list) to its own line but otherwise this seems like a straightforward list comprehension to me.
    – Scott Lobdell
    Apr 16 '15 at 19:40












  • "If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
    – Aiden Bell
    Apr 16 '15 at 21:02








  • 1




    In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
    – Aiden Bell
    Apr 16 '15 at 21:04








  • 1




    @ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
    – Aiden Bell
    Apr 18 '15 at 17:55















up vote
0
down vote













If it were me I'd just go for brevity and ensure the function name is expressive:



def silly_case(input_string):
return "".join([char.lower() if index < (len(input_string) + 1)/ 2 else char.upper() for index, char in enumerate(input_string)])


EDIT:



I've gotten lots of criticism for my answer for stuffing things to one line, but I'm still a fan of list comprehensions, and I find it completely intuitive. Based on the feedback, here's how I would implement this function:



def silly_case(input_string):
pivot_index = (len(input_string) + 1) / 2
char_list = [char.lower() if index < pivot_index else char.upper() for index, char in enumerate(input_string)]
return "".join(char_list)





share|improve this answer



















  • 2




    Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
    – Aiden Bell
    Apr 15 '15 at 21:09










  • If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change (len(input_string) + 1)/ 2 to pivot_index and perhaps move "".join(string_as_list) to its own line but otherwise this seems like a straightforward list comprehension to me.
    – Scott Lobdell
    Apr 16 '15 at 19:40












  • "If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
    – Aiden Bell
    Apr 16 '15 at 21:02








  • 1




    In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
    – Aiden Bell
    Apr 16 '15 at 21:04








  • 1




    @ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
    – Aiden Bell
    Apr 18 '15 at 17:55













up vote
0
down vote










up vote
0
down vote









If it were me I'd just go for brevity and ensure the function name is expressive:



def silly_case(input_string):
return "".join([char.lower() if index < (len(input_string) + 1)/ 2 else char.upper() for index, char in enumerate(input_string)])


EDIT:



I've gotten lots of criticism for my answer for stuffing things to one line, but I'm still a fan of list comprehensions, and I find it completely intuitive. Based on the feedback, here's how I would implement this function:



def silly_case(input_string):
pivot_index = (len(input_string) + 1) / 2
char_list = [char.lower() if index < pivot_index else char.upper() for index, char in enumerate(input_string)]
return "".join(char_list)





share|improve this answer














If it were me I'd just go for brevity and ensure the function name is expressive:



def silly_case(input_string):
return "".join([char.lower() if index < (len(input_string) + 1)/ 2 else char.upper() for index, char in enumerate(input_string)])


EDIT:



I've gotten lots of criticism for my answer for stuffing things to one line, but I'm still a fan of list comprehensions, and I find it completely intuitive. Based on the feedback, here's how I would implement this function:



def silly_case(input_string):
pivot_index = (len(input_string) + 1) / 2
char_list = [char.lower() if index < pivot_index else char.upper() for index, char in enumerate(input_string)]
return "".join(char_list)






share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 17 '15 at 5:18

























answered Apr 15 '15 at 4:12









Scott Lobdell

1452




1452








  • 2




    Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
    – Aiden Bell
    Apr 15 '15 at 21:09










  • If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change (len(input_string) + 1)/ 2 to pivot_index and perhaps move "".join(string_as_list) to its own line but otherwise this seems like a straightforward list comprehension to me.
    – Scott Lobdell
    Apr 16 '15 at 19:40












  • "If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
    – Aiden Bell
    Apr 16 '15 at 21:02








  • 1




    In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
    – Aiden Bell
    Apr 16 '15 at 21:04








  • 1




    @ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
    – Aiden Bell
    Apr 18 '15 at 17:55














  • 2




    Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
    – Aiden Bell
    Apr 15 '15 at 21:09










  • If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change (len(input_string) + 1)/ 2 to pivot_index and perhaps move "".join(string_as_list) to its own line but otherwise this seems like a straightforward list comprehension to me.
    – Scott Lobdell
    Apr 16 '15 at 19:40












  • "If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
    – Aiden Bell
    Apr 16 '15 at 21:02








  • 1




    In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
    – Aiden Bell
    Apr 16 '15 at 21:04








  • 1




    @ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
    – Aiden Bell
    Apr 18 '15 at 17:55








2




2




Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
– Aiden Bell
Apr 15 '15 at 21:09




Brevity as a positive falls down when code isn't readable. Unreadable or unreasonable code costs more in terms of bugs than a few extra tokens. Perhaps i'm missing the point of the site, but if I saw this going in to production the author would be forced to rewrite it.
– Aiden Bell
Apr 15 '15 at 21:09












If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change (len(input_string) + 1)/ 2 to pivot_index and perhaps move "".join(string_as_list) to its own line but otherwise this seems like a straightforward list comprehension to me.
– Scott Lobdell
Apr 16 '15 at 19:40






If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable? If anything I might change (len(input_string) + 1)/ 2 to pivot_index and perhaps move "".join(string_as_list) to its own line but otherwise this seems like a straightforward list comprehension to me.
– Scott Lobdell
Apr 16 '15 at 19:40














"If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
– Aiden Bell
Apr 16 '15 at 21:02






"If a function is 1 line and it's well-named (here it's just "silly_case"), and there's test coverage for that function, do you still find that 1 line unreadable?" ... yes, a million times yes. Character efficiency in code is not equal to computational efficiency, and even if it were, i'd still insist on a rewrite unless it was in some uber critical performance path. Yes, the situations in which this is acceptable IMHO are very, very rare. 99.99% of the time i'd take readable code over fast or succinct code.
– Aiden Bell
Apr 16 '15 at 21:02






1




1




In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
– Aiden Bell
Apr 16 '15 at 21:04






In short, I see zero benefit to this being a long one liner vs a readable multiple line implementation ... that's ignoring the fact it is 129 characters long!
– Aiden Bell
Apr 16 '15 at 21:04






1




1




@ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
– Aiden Bell
Apr 18 '15 at 17:55




@ScottLobdell - In fairness, this is a code review site. I love list comprehension, but not at that price ;) Anyway, each to their own.
– Aiden Bell
Apr 18 '15 at 17:55


















draft saved

draft discarded




















































Thanks for contributing an answer to Code Review 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.


Use MathJax to format equations. MathJax reference.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • 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.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f86933%2fsplit-string-in-half-and-change-case-accordingly%23new-answer', 'question_page');
}
);

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







Popular posts from this blog

Morgemoulin

Scott Moir

Souastre