Timeline for Interview coding test: Fizz Buzz
Current License: CC BY-SA 3.0
33 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 1, 2016 at 20:12 | comment | added | mbomb007 | blog.codinghorror.com/code-tells-you-how-comments-tell-you-why | |
| May 1, 2016 at 16:45 | comment | added | Software Engineer | codeodor.com/index.cfm/2008/6/18/… and blog.codinghorror.com/coding-without-comments too | |
| May 1, 2016 at 16:28 | comment | added | Software Engineer | @mbomb007 The consensus of opinion from very senior well-respected engineers is that comments are considered bad and should be avoided. The weight of evidence seems to be against you. Checkout: butunclebob.com/ArticleS.TimOttinger.ApologizeIncode and alvinalexander.com/programming/… (search for 'comments'), visualstudiomagazine.com/articles/2013/07/26/…. Of course, I've picked links that argue my case, but it's hard to find any contemporary links that successfully argue yours. | |
| May 1, 2016 at 2:20 | comment | added | mbomb007 | @EngineerDollery Well, I already have a job, and I can say that you're wrong. Comments are very helpful. Just because you can understand the code now doesn't mean you will if you look at it again in a year. Understanding how an application works often requires viewing lots of code and large parts of the app. If you want to know what a piece does quickly, a comment is worth your time. They don't slow the code down, so put it in there. | |
| May 1, 2016 at 0:29 | history | edited | Software Engineer | CC BY-SA 3.0 | added 452 characters in body |
| May 1, 2016 at 0:19 | comment | added | Software Engineer | @BenjaminGruenbaum -- you're fired ;) | |
| Apr 30, 2016 at 6:59 | comment | added | Benjamin Gruenbaum | Here is my implementation of choice, a lot more generic github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition 5000 GH stars so it's web-scale. | |
| Apr 29, 2016 at 22:15 | comment | added | Drathier | I find your usage of nested ternary statements are hard to read. I initially thought it was some new language feature. It took a while to realize what you had done. | |
| Apr 29, 2016 at 10:44 | answer | added | OldCurmudgeon | timeline score: 0 | |
| Apr 29, 2016 at 2:10 | comment | added | Software Engineer | Agreed. Which is why I actually stated 'should be avoided as much as possible'. I think you may have misread this, or read more emphasis into it than I intended. Personally, I wrote a comment only last year, and I didn't even bother removing it because it explained code that implemented a ridiculous requirement that someone was willing to pay to have implemented despite my professional protests. And, occasionally, I'll use a comment to explain a broken api that needs working around. | |
| Apr 29, 2016 at 1:59 | comment | added | AaronLS | @EngineerDollery Comments don't always mean code needs to be refactored. Stating that as an absolute is ridiculous. | |
| Apr 29, 2016 at 0:47 | vote | accept | Software Engineer | ||
| Apr 29, 2016 at 0:35 | vote | accept | Software Engineer | ||
| Apr 29, 2016 at 0:39 | |||||
| Apr 29, 2016 at 0:32 | comment | added | Software Engineer | @mbomb007 -- actually, comments are an horrendous code smell and should be avoided as much as possible. I'm not talking about documenting interfaces, that's totally different. I'm talking about comments -- they indicate that the code itself isn't clear enough and needs to be refactored/rethought. If you find yourself writing a comment, take a moment and ask yourself why your code isn't clear enough to stand on its own merits. Further, modern teams often consist of people from many nationalities. Java is a formal description in a shared language that they all can understand without ambiguity. | |
| Apr 28, 2016 at 21:59 | comment | added | mbomb007 | Good programmers should also write their code to be understandable and with comments. Using Java 8 features makes it less readable than simply using a standard For loop, which has been around longer. The FizzBuzz task is pretty simple, of course, but comments couldn't hurt. | |
| Apr 28, 2016 at 21:21 | comment | added | Dzhao | A small note that the answers haven't covered. In regards to formatting, some lines are just awfully long. While not as important as the issues in the answers, it is still a factor to writing readable code. | |
| Apr 28, 2016 at 14:57 | comment | added | Mindwin Remember Monica | @EngineerDollery ask that question to any obfuscated C contestant... | |
| Apr 28, 2016 at 14:02 | answer | added | Yakk | timeline score: 1 | |
| Apr 28, 2016 at 0:59 | vote | accept | Software Engineer | ||
| Apr 29, 2016 at 0:34 | |||||
| Apr 28, 2016 at 0:54 | vote | accept | Software Engineer | ||
| Apr 28, 2016 at 0:59 | |||||
| Apr 28, 2016 at 0:03 | review | Close votes | |||
| Apr 28, 2016 at 6:23 | |||||
| Apr 27, 2016 at 23:04 | history | edited | Jamal | CC BY-SA 3.0 | deleted 19 characters in body; edited title |
| Apr 27, 2016 at 22:50 | answer | added | Necreaux | timeline score: 6 | |
| Apr 27, 2016 at 22:15 | answer | added | brian_o | timeline score: 25 | |
| Apr 27, 2016 at 22:10 | answer | added | Tom Eberhard | timeline score: 16 | |
| Apr 27, 2016 at 16:06 | history | tweeted | twitter.com/StackCodeReview/status/725355444223528960 | ||
| Apr 27, 2016 at 15:35 | comment | added | Mathieu Guindon | (that comment was meant to be under my answer, right?) -- IMO it's not about implementing patterns (although those are a valuable tool for this), it's about identifying the points of change, the implicit assumptions, the things that the business can decide to change on a whim... and then writing code that only needs to change minimally when your assumptions are shattered and the specs do change: that's what my point about flexibility/maintainability was. Keep in mind that FizzBuzz is an exercise, a metaphor for real-world code. | |
| Apr 27, 2016 at 15:20 | comment | added | Software Engineer | On your first comment concerning maintainability... I did consider this, but the implementation of the first two versions of the code is basically a single line of code, and I couldn't envision using a couple of dozen implementing a pattern or two actually making it more maintainable -- because it's just a single line. Granted, it is a display of technical knowledge that reduced this to a single line, and it's only a single line because of the fluent interface used for stream processing in java 8, but still -- how much more maintainable can a single line of code get? | |
| Apr 27, 2016 at 15:10 | history | edited | Tunaki | CC BY-SA 3.0 | added 322 characters in body |
| Apr 27, 2016 at 15:04 | answer | added | Tunaki | timeline score: 26 | |
| Apr 27, 2016 at 15:01 | answer | added | Mathieu Guindon | timeline score: 60 | |
| Apr 27, 2016 at 14:31 | review | First posts | |||
| Apr 27, 2016 at 15:07 | |||||
| Apr 27, 2016 at 14:26 | history | asked | Software Engineer | CC BY-SA 3.0 |