61–70 of 80 posts
Earlier quoted context omitted.
In a code review, I’d given a junior programmer advice to avoid magic constants and use defines instead (c, not c++). Resubmission came back with: #define SEVENTEEN 17 Last I spoke with him, he was a Java instructor.
The truly brilliant thing to do would be #define SEVENTEEN 16
> You have a tendency to overengineer things. Overengineering is an actual problem. For a tiny example, I'll see things like: enum MAGIC = 67; // explanation ... foo(MAGIC); The use of MAGIC is the only one, and is far removed. A better solution is: foo(67); // explanation because it improves locality. I also see things like an object fleshed out with all kinds of member functions that are never used.
Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Naomi_Uemura This man has won the People's Honour Award for climbing the highest mountains on 5 continents and being the first man to reach the north pole solo. So Naomi is not necessarily a dead giveaway, you guys really split hairs and raise hackles over just about nothing worthwhile. Mistaking someone's sex is not a massive deal. I used to have on my team a guy named Joan (pronounced…
Does finding an instance of a male named Naomi really convince you that Naomi is not typically a female name?
And this is on top of calling someone else out for presuming something... and here you all are presuming that Naomi is a feminine name.
We're making a mountain out of a molehill here. This is a persistent and pernicious problem in society at large now. What is the actual point of calling out any POSSIBLE perceived remote slight that you really have to perform mental gymnastics in bad faith to even arrive at?
There was no malicious intent on the part of the original poster, and yet they are excoriated for nothing?
What a massive amount of spare time we all have to waste.
Especially when it is a unisex name.
We could be doing something to better our world, and we spend time _on this_. We do it every day on a massive scale. It's so tiring, so wasteful, and so lamentably useless when there are so many useful and actually kind things we could be doing, instead of just virtue-signalling fake empathy on the internet that amounts to nothing.
(defn any-buzz
[num & words]
(or (not-empty (reduce str words))
num))
(map any-buzz
(range 1 16)
(cycle [nil nil "Fizz"])
(cycle [nil nil nil nil "Buzz"]))
https://www.evalapply.org/posts/n-ways-to-fizzbuzz-in-clojur...
edit: formatting, detail
In the end the only "subversion" is that it was written as zipped infinite ranges rather than an explicit for-loop.
Earlier quoted context omitted.
The name Naomi might have been a dead giveaway.
https://en.wikipedia.org/wiki/Naomi_Uemura This man has won the People's Honour Award for climbing the highest mountains on 5 continents and being the first man to reach the north pole solo. So Naomi is not necessarily a dead giveaway, you guys really split hairs and raise hackles over just about nothing worthwhile. Mistaking someone's sex is not a massive deal. I used to have on my team a guy named Joan (pronounced…
> You have a tendency to overengineer things. Overengineering is an actual problem. For a tiny example, I'll see things like: enum MAGIC = 67; // explanation ... foo(MAGIC); The use of MAGIC is the only one, and is far removed. A better solution is: foo(67); // explanation because it improves locality. I also see things like an object fleshed out with all kinds of member functions that are never used.
I see where you're going. You never know when MAGIC will be needed and whether or not it will remain constant. It also doesn't scale horizontally. The right answer if you want to be fully robust is to make a Magic microservice that will return the magic number when needed and autoscale on demand. You could have the swagger doc for the service include the explanation.
The best approach if you want to be future-proof while would be to label the instance in-place, so that you can look later for places where #MAGIC is being used, without losing locality:
foo(67); // #MAGIC explanation ruby -e 'puts (0..99).map {|i| srand(46308667) if (i%15).zero?; ["FizzBuzz", "Buzz", i+1, "Fizz"][rand(4)]}'There is “no way” to subvert this FizzBuzz interview when writing code in Python 3 only. def inf_range(a): while True: yield a a += 1 def take(n, it): return [a for a, b in zip(it, range(n))] def fizzbuzz(): return (a + b or str(c) for a, b, c in zip( (a for _ in inf_range(1) for a in (("", "", "Fizz"))), (a for _ in inf_range(1) for a in (("", "", "", "", "Buzz"))), inf_range(1))) print(take(30, fizzbuzz())) For bon…
I always liked the version with no branching statements. In python it would be roughly: def fizz_str(n): return "FIZZ" def buzz_str(n): return "BUZZ" def fizz_buzz_str(n): return "FIZZBUZZ" def to_str(n): return str(n) indexes = [3, 0, 0, 1, 0, 2, 1, 0, 0, 1, 2, 0, 1, 0, 0] def fizz_buzz(n): funcs = [ to_str, fizz_str, buzz_str, fizz_buzz_str ] return funcs[indexes[n % 15]](n) for i in range(1, 101): print(fizz_buzz(…
I never noticed this symmetry in fizzbuzz before.
Earlier quoted context omitted.
I see where you're going. You never know when MAGIC will be needed and whether or not it will remain constant. It also doesn't scale horizontally. The right answer if you want to be fully robust is to make a Magic microservice that will return the magic number when needed and autoscale on demand. You could have the swagger doc for the service include the explanation.
You're joking, but your description of a prepare-for-any-circumstance mentality summarizes exactly the problem, you never know if MAGIC will be needed or not remain constant, so assuming it will not and making your program structure more complex for it is overengineering. The best approach if you want to be future-proof while would be to label the instance in-place, so that you can look later for places where #MAGIC…