Name: Anonymous 2015-06-19 7:00
When I think about it, I probably would have failed the code smell part as well: over the years, I have seen the utter superiority of the Algol-68 style over the C style in most cases. This has consequences:
I sometimes use the ternary operator to initialize variables (or should I say constants). The only thing ugly about this operator is its syntax. Its semantics are cleaner than those of if(){}else{}, its more readable equivalent.
I often use multiple returns. It's the only way I can use if(){}else{} without relying on side effects.
I don't shy away from switch statements, or their cascaded if() equivalents. I may even use a cascaded ternary operator. See, most of the time, the Expression Problem leans heavily in favour of sum types (tagged unions) and pattern matching, instead of class hierachies. Java lacks sum types, so this means emulating them with a switch statement. This is cumbersome, but less so than the equivalent class hierachy.
I shun getters and setters. While I like my objects to be immutable, sometimes I do need a public mutable member variable. Well, I'm honest about it, and use just that. I dont hide it under the getter/setter carpet, unless it actually helps me enforce some specific invariant. And I call my getters "foo()", instead of the more customary "getFoo()". I want to emphasise the result, not the action of getting it.
I will probably end up writing Algol-68 in Java (except when it means fighting the interfaces around me, including the standard library). But I do believe this generally results in shorter, cleaner, more reliable code than idomatic Java. This stays true even in the face of readability issues ("readability" means you can't use recursion, closures, or even first class booleans, because your poor colleagues lack some basic education —this is not a strawman, I have lived it).
So, your code smell may very well be my best practice.
This interview process would likely reject me. Unless the interviewer has a relatively solid understanding of Algol-68 programming, he will just mark me off as sloppy, too clever, ignorant of OO principles, or even all three. I can explain myself, but I only have half an hour, and this comment already took me twice that.
I sometimes use the ternary operator to initialize variables (or should I say constants). The only thing ugly about this operator is its syntax. Its semantics are cleaner than those of if(){}else{}, its more readable equivalent.
I often use multiple returns. It's the only way I can use if(){}else{} without relying on side effects.
I don't shy away from switch statements, or their cascaded if() equivalents. I may even use a cascaded ternary operator. See, most of the time, the Expression Problem leans heavily in favour of sum types (tagged unions) and pattern matching, instead of class hierachies. Java lacks sum types, so this means emulating them with a switch statement. This is cumbersome, but less so than the equivalent class hierachy.
I shun getters and setters. While I like my objects to be immutable, sometimes I do need a public mutable member variable. Well, I'm honest about it, and use just that. I dont hide it under the getter/setter carpet, unless it actually helps me enforce some specific invariant. And I call my getters "foo()", instead of the more customary "getFoo()". I want to emphasise the result, not the action of getting it.
I will probably end up writing Algol-68 in Java (except when it means fighting the interfaces around me, including the standard library). But I do believe this generally results in shorter, cleaner, more reliable code than idomatic Java. This stays true even in the face of readability issues ("readability" means you can't use recursion, closures, or even first class booleans, because your poor colleagues lack some basic education —this is not a strawman, I have lived it).
So, your code smell may very well be my best practice.
This interview process would likely reject me. Unless the interviewer has a relatively solid understanding of Algol-68 programming, he will just mark me off as sloppy, too clever, ignorant of OO principles, or even all three. I can explain myself, but I only have half an hour, and this comment already took me twice that.