I for one would have failed the testing part entierly, for two reasons:
First, for a refactoring job, I would have assumed this was not running code, but a subset of something bigger. I would hardly expect it to even compile, let alone pass tests. If I took this interview, I may have noticed the presence of tests, and I may have ran them if I did notice. Pretty unlikely.
Second, most of the refactoring I have done so far is based on local, semantic-preserving, transformations. Those are extremely reliable (as in a couple mistakes every 50 modifications). No point in running tests every few edits, unless they're less than two kestrokes (and seconds) away. If I do get in trouble, I still have Git.
---
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 functional style over the imperative 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 imperative 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 ML 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 functional 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.
First, for a refactoring job, I would have assumed this was not running code, but a subset of something bigger. I would hardly expect it to even compile, let alone pass tests. If I took this interview, I may have noticed the presence of tests, and I may have ran them if I did notice. Pretty unlikely.
Second, most of the refactoring I have done so far is based on local, semantic-preserving, transformations. Those are extremely reliable (as in a couple mistakes every 50 modifications). No point in running tests every few edits, unless they're less than two kestrokes (and seconds) away. If I do get in trouble, I still have Git.
---
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 functional style over the imperative 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 imperative 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 ML 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 functional 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.