229 karma · joined December 21, 2014
I have never used emacs, but vim is horribly limited in what it can truly do in terms of handling code. You can add all the nifty little plugins you want, but it just isn't efficient. The mistake people make moving to a full IDE is installing the vim plugin to add some familiarity. I've seen coworkers take literally 5 minutes to hammer out the vim keystrokes to refactor a block of code that can be done in 15-30 seconds with 2-3 native IDE keyboard shortcuts and a mouse click or two. It's important to know how to use vim or similar for remote command-line work. When developing though, the functionality and built-in tools provided by a full-fledged IDE are priceless.
There was a time I didn't judge new developers for using vim to edit code - and a long time ago I was one of them. I used to see these people as "true developers" for mastering an editor like vim. Now, after years of encountering developers with hampered productivity and ability to work on a team with coding standards, I see a vim/emacs person as someone who is stuck in their ways, refusing to even try to modernize their workflow.
Just a random example: in PHP projects, my teams use CodeSniffer for coding standards validation. The settings for common IDEs are committed to the VCS so they are automatically in place for new developers cloning the project. In any modern IDE, notices/warnings are instantly and unobtrusively made available as you type code. You can also run the inspection against the entire codebase or files you have modified since last VCS update to catch anything you missed.
What do Vim users do? They write code for hours or days at a time without validating what they are writing. When done, they either a) commit without running their code against CodeSniffer while egotistically proclaiming that their personal coding style is clean and doesn't need to match what the rest of the team abides by; or b) they spend hours running the command-line version manually, ridiculously trying to parse the output and hunt each problem down.
This is the real problem with vim/emacs users. Nearly none of them are capable of following the same coding practices as the rest of the team who are sharing a set of project settings in modern IDEs. The worst I've seen was a team that had once had amazing code quality completely abandon all forms of coding standards when two new senior developers were hired who both used vim. They refused to follow the standards because vim simply doesn't contain the necessary tooling. The entire codebase went from being beautifully clean to a complete mess, all because the new guys used vim. That was the job I walked away from so fast after fighting over the ridiculousness and then learning that both new developers were basically hired for the simple reason they went to the same university as the hiring manager.
tldr; Use vim/emacs if you want; but if you're not going to be as productive as, or match the code quality of, your teammates - that's a problem.
By the way, your method of popping up the div overlay removes the scrollbar if present (at least in your demo), which makes centred layouts jump around. Raises a yellow flag regarding implementation quality.
Photo printing is already cheap. If you can't afford to print photos, you probably also can't afford to buy the camera or the memory card (or the film and development for you old-schoolers).
This is a sad world we live in. Advertising in every place imaginable. You want to know where I'd be okay with your visual spam? On toilet paper. Print your advertising on my free toilet paper so I can wipe my ass with it.
I tend to find only one use case where I find a plural form simply appears more natural: prefixing it with "the", as in "The mathematics necessary to explain the universe are complex." Replacing the "are" with "is" just does not sound right. Funnily enough, the natural pattern with the North American "math" becomes "The math necessary to explain the universe is complex.".
Damn you, strange collective noun.
On a related note, my high school had an Advanced Placement English class offered to students selected by previous semesters' English teachers. This option came with an unfortunate snag for all students enrolled in the French immersion track: both the AP English class and a required French class occupied the same period. We were frankly offered the choice to stick with the French immersion we'd been part of for more than 10 years (having started in kindergarten), or to convert to the English track by dropping all French-language classes entirely.
Yeah, the AP class that year was quite small with not a single person dropping the French track. It turns out that people enrolled in the French track are much more likely to land placement in AP English, as being fluent in more than one language steers a person into understanding and appreciating languages more than someone immersed in a single language. Such a ridiculous scheduling blunder by the administration; just the memory of not being part of that class more than 10 years ago makes me sad.
[1] Having grown up in North America where it is common to refer to mathematics as the singular "math", it is still weird to type "maths" even after having picked up the habit a few years ago.
If anything, you'd think the cheaper meal should have a larger tip since you're occupying a spot for a cheap meal when they could have had a client sit down and spend 3x as much as you. It's all backwards, the fact that the tip is based on the dollar amount of the meal...
1. You have a dangling check for empty string at the end to set to the current number if the string is empty after the Fizz/Buzz conditions. An "else" clause disguised as an "if" clause.
2. It's just messier to understand. "If % 3, append Fizz; if % 5, append Buzz" has four different outcomes: neither matches, first matches, second matches, both match. A newcomer to the code has to mentally separate out all possibilities (which basically requires re-scanning the same code four times). Whereas the "if, elseif, elseif, else" can be read over and understood with a single scan.
Then again it is FizzBuzz and not FizzBuzzMozz, where numbers divisible by both 3 and 5 produce a string that cannot be concatenated by the individual 3 and 5. So to be fair, this solution is perfectly valid. :p
My personal preference in terms of demonstrating maintainable code is using two modulus operations with variables. However, I fully understand the argument that an additional % 15 is preferable compared to the overhead of storing two variables on each iteration. Both are valid approaches IMO, and the debate can roar on for eternity. Micro-optimizations and whatnot.
I just don't like to see four modulus operations, which IMO shows a lack of basic willingness or ability to refactor while coding. It's fine to initially write the four modulus operations, but if someone doesn't immediately catch the duplication and do something about it, it screams "I write code until it works and then move on without cleaning anything up."
Strangely enough, only once have I seen someone use the % 15 optimization and add a short comment along the lines of "// least common multiple, divisible by both 3 and 5". Spotting the optimization is nice; placing a short comment explaining why % 15 when the test is about % 5 and % 3 is a nice touch. Explains something that might not be immediately obvious to the next person coming to the code.
Aside: it astounds me how many people, when asked to write a short snippet of code during an interview, have basic formatting problems and inconsistent code style. I've seen two lines of code inside an if() block indented at different levels, with no excuse for "different opinions on formatting". Not a wrapped line continued on the next, but just two simple statements inexcusably indented at say 8 and 12 spaces. Don't call us, we'll call you...