skysight-inc/HackerNews huggingface dataset:
Facebook applications anti-social not Open Social
Quality code is any code written by me.
Poor code is any code not written by me.

me = any developer

:o)
Screen Resolutions and Better User Experience
This is a great presentation including small samples of Javascript showing off all the cool parts. (I'm adding this comment to catch folks that might have missed the article post but are reading the new comments page) It's a cool resource for folks wanting to do a quick check of their JavaScript programming chops.
"...and it often simplifies the code to have multiple returns."

Today. And what happens after 10 other programmers modify your slick little multi-return function? Nobody will ever be able to modify it again because the entries and exits are lost among the garbage. This is the ongoing debate I've had for years with "clever programmers". They're missing one critical point: the guidelines of structured programming are not meant to make your life easier; they're meant to keep the code alive longer by making life easier for the poor schmuck who has maintain it (usually me).

Another Sign You're a Crappy Programmer:

You make your own rules in direct violation of effective established principles because you think you know better.
Most of the comments here are in regards to maintainability and conciseness. There are comments like: quality code is elegant. But saying that code is "elegant" is the same as "quality".

Can the person who writes the code be the authority on whether it is quality code? If one of the most important aspects of quality code is how easy it is to maintain or extend. Shouldn't it follow that code shouldn't be considered good until it's maintained or extended.
Angel financing - What angels look for in a company: Management
10 Real Signs You're a Crappy Programmer:

10. The exact same code is in multiple places because you didn't bother to put in into a common function.

9. You have error codes in functions, but never bother to look at them (a sure sign that testing was never finished).

8. You have early exits from loops because you don't know how to properly code a recursion.

7. You execute too much code because you don't know the difference between "if" and "case".

6. You use 10 lines of code when 1 line would do because you don't know any better.

5. You need to run batch jobs from time to time to clean up your data base because you don't know how to debug well enough to find what's messing it up.

4. A third grader doesn't know what your variable names mean.

3. You think "Third Normal Form" is paperwork you need to fill out for one of your 8 bosses.

2. No programmer who has to maintain your code would ever want to work with you.

1. Any programmer that has to maintain your code would be more than happy to accept the consequences of first degree murder.
http://payplay.fm/
About X Windows...the last person to study its source code mysteriously died 7 days later: http://en.wikipedia.org/wiki/The_Ring_%282002_film%29
0. You refuse to use recursion even when working with a language that supports it properly because you think it's horribly slow.
Java is not the most loved language around here but check out the Java API.

Some of the books you might want to read:

1) Code Complete (MS Press)

2) Effective Java/C++ (Joshua Bloch/Scott Meyers)

3) Design Patterns

4) Refactoring

I don't know other books/library that can answer this question from other language (such as LISP, Python and Ruby)
"8. You have early exits from loops because you don't know how to properly code a recursion."

Wow. Not every problem calls for recursion. If you really hate early exits from loops, maybe you should just code the loop's condition differently.
(6) Happens even when you know better.

(10) Good programmers don't repeat themselves, true, and to continually improve as a programmer it is important to patiently do everything correctly the first time. However, obsessing over a few bits of code duplication is often a complete waste of time.
Mark Cuban Calls on ISPs to Block P2P
Early returns make code more readable. I'd rather detect an error and bail then have a slew of nested ifs.

It isn't always about being clever.
"IBM is said to love buying Canadian companies like Cognos because of their tremendous employee stickiness. Next time one of my American clients ridicules Canada's pro-employee ways, I'll remind them of this."

I didn't know Canada had "pro-employee ways" (whatever that is), let alone that they were being ridiculed for it by Americans. Last time I checked, Canadian companies were just as interested in down-sizing as American companies are. The "employee stickiness" IBM is talking about probably has more to do with the mindset of employees in Canada rather than anything employers or the government might be doing. Maybe Canadians are more reluctant to move cities for a different job than Americans are, but the people I know in IT in Canada, at least, have no qualms about leaving their jobs if they can find something better. Even people at Cognos.
"...obsessing over a few bits of code duplication is often a complete waste of time."

For you, maybe. But what about the guy who applies enhancements 3 years later and has trouble getting through testing because the exact same code was somewhere else and difficult to find because of the 67 mods since then.

Minutes "obsessing" today usually saves hours testing tomorrow.
"If you really hate early exits from loops, maybe you should just code the loop's condition differently."

Exactly.

Like I mentioned before, I'm the poor schmuck that has to clean it up because someone didn't bother to take your (common sense) advice years ago.
>>5. Starve existing (and possible) social networks of users through network effects and platform lock-in (done)

This is what Microsoft did. Maybe not necessarily with "social networks," but in principle. The fact that this little iteration of 'lock-in' is both preceded and followed by a "getting investment money" cycle would be a cause of alarm to me if I were a potential facebook investor or employee. Scratch the "investment" word and you're left with just "getting money." Welcome to the real world.

Lock-in is not a sustainable means of long-term growth, revenue, or profit. Obfuscating code behind a bunch of platform-specific run-around gibberish and license lawsuit nonsense doesn't benefit users and gives developers major headaches. Lawyers do seem to like it, though, since they always are "getting money".

As history has shown, superior, non-obfuscated, legal, free! open-source code will inevitably appear on the outside of any lock-in. Lock-in creates something known in management as "groupthink" and it's almost never (ouch, sorry for the pun) "group_wise_". Groupthink causes those on the inside to value that which is on the inside > the market is able to value it. There's a reason disclosure is required in the world of securities: it's called "insider trading."

So for long-term strategy, I'd say facebook flubbed bigtime by being greedy. Being greedy ala-Microsoft and "not accepting anything less than a billion" or . . . whatever the tipping point was that caused them to jump in the stew with Microsoft specifically . . . that was really just not smart. Trying to be too many things to too many people?

The Internet was built for niche markets. I'm hopeful on the open source niche. :)
British economy suffers brain drain as skilled workers take flight
"Minutes "obsessing" today usually saves hours testing tomorrow."

True, but the app has to make it to tomorrow for testing to matter at all. It's better to be in the championship trying to figure out how to manage a tired team, than it is to conserve energy during the semifinals and wind up sitting in the bleachers.
"I'd rather detect an error and bail then have a slew of nested ifs."

And here's what inevitably happens when you do that:

14 mods are applied and your early exit(s) get lost in the muck.

Programmer 15 puts his mod ON THE WRONG SIDE of your early exit because he never saw it. He doesn't do regression testing, and the data base gets screwed up over the next 6 months.

Then I come along, find the errors, fix the data base, advise the user of the effects of the damage, and rewrite the whole program with single entry/single exit processing so that this never happens again. And then post to a board like this only to re-engage in the same old debate.

Aside from poorly named variables, violation of "single entry/single exit" is the biggest lifespan reducing problem of code bases I've ever seen.

This is the future speaking. Please don't do that.
Java APIs err on the side of overengineering - and it's not the language, it's the culture around it.

I do recommend Effective Java and Effective C++ (and its sequels). They show the limitations of the respective languages and how to overcome them.
Sometimes it makes more sense to bail early than it would to restructure. It could be that its more readable, or a more natural progression of things. Take this paper:

http://www.csd.uwo.ca/~yuri/Papers/pami04.pdf

It's really great, for the record. Anyway, the algorithm they wrote uses an early exit. In fact, they use a while(true), the "worst case" example.

initialize: S = {s}, T = {t}, A = {s, t}, O = {(Empty Set)}
while true
grow S or T to find an augmenting path P from s to t
if P = {(Empty Set)} terminate
augment on P
adopt orphans
end while

In programming this algorithm, sure, I could probably move the first grow before the loop, and grow at the end. But, now its harder to understand, and violates the afore mentioned copy paste rule.

My point is this, take any such "rule" with a grain of salt. There are plenty of examples where it makes sense to do something atypical.
Where'd you ever get the idea that there is any trade-off between "quick" and "right"?

Doing things according to effective established principles saves a little time today and a lot of time tomorrow.

Quick and dirty usually ends up being neither.
"employee stickiness" is a bad sign for employees. It means that finding and keeping a rewarding job is hard.
"violates the afore mentioned copy paste rule"

Put it in a common function. Sure, it may look a little frazzled today, but generations of future hackers will thank you.
"Maybe Canadians are more reluctant to move cities for a different job than Americans are"

Canadians love living in Canada and in general move to the US very reluctantly. As a result Canadians have fewer career options relative to their US counterparts. This results in low turnover. You're right, it has nothing to do with a company's "pro-employee" which I assume means "employee-friendly" ways.
Or that an employee has "stuck" around for long enough to be unemployable elsewhere.
I see where you are coming from, but I'm just not buying it. First, 15 different programmers are rarely touching the same piece of code over any short or medium span of time. Second, even over the long term, if you have programmers who don't read the code they are making changes to before they change it, you should fire them.

You can make the same argument that a bunch of nested ifs is going to end up with a lazy programmer who doesn't know what conditions need to be met, so he puts it in the wrong place, and now all of your careful code is broken. Coding style is ultimately pretty personal, and this is no different.
Questions I have would be:

Why is the function being modified 14 times? It sounds like the original abstraction was poorly conceived. I would hope that at some point before edit #15, someone would think to break the function down into smaller pieces.
You're still making two function calls when you could be making one. If one of them gets lost in the fray, you'll spend just as much time solving that problem.
"obsessing over a few bits of code duplication..."

Applying good coupling and cohesion principles is not obsessing. It's as much legitimate programming as writing an equality test.
The slideshow is a bunch of JS introduction, and barely any "metaprogramming". If you are really looking for a good JS read, check out this article:

http://simon.incutio.com/slides/2006/etech/javascript/js-rei...
I have to disagree with #6. You can either write code for the compiler or the human. I prefer to write it for the human, because a lot of times the compiler understands exactly what's going on, but I'm pretty clueless when I come back after only a few days. I think you meant not understanding how the language works so using a lot of extra commands when one would do. However it's common to "dumb down" your code, especially if it is tricky, for the poor schmuck that has to maintain it. Remember -- writing code should not be like writing a mystery novel.
Couldn't agree more. FInding right employees at right prices is extremely hard to do in the Valley. You're competing with the likes of Google, Facebook etc and it can take forever to fill a position at an inflated price. While you're small and your startup consists of a few founders, there's no better place on Earth to be at but as soon as you get that check from a VC, things are gonna get tough.
"a language that supports it properly..."

Meaning what exactly? A language that automatically optimized for tail recursion? Are there languages which don't support recursion "properly?"
The standard of living has increased seven-fold in the past century. As a result, the definition of "poverty" is no longer homeless people starving to death, but a family living in a small house who own a car, TV set, and other "luxuries." Yeah, I think capitalism has done a lot to "take care" of people.

And actually, the incentives to "subsidize" the disadvantage have always been there (why do middle-class atheists give to charity?), but that gets into sociobiology.
Thanks. That was a good link. I have bookmarked it.

It's much more explanatory, though. I believe the intent of the main linked article is a presentation giving more of a tour to what is possible. The author makes clear at the end that the reader might not get it all -- it's just an overview.

I didn't find much difference in terms of metaprogramming, however. Were there any concepts in your article that weren't mentioned in the first one? I might have missed it.

I'd use the presentation as a way of glossing over the high points, and then refer somebody to your link as a way of figuring out how it all works.
"Programmer 15 puts his mod ON THE WRONG SIDE of your early exit because he never saw it. He doesn't do regression testing, and the data base gets screwed up over the next 6 months."

I can certainly see how this is true in a large organization which hires lots of mediocre programmers. However, if you're in a company where the other programmers are top notch, this sort of thing is not a problem.

In fact, if I ever see nested ifs and such in a function where I work, it gets changed to the least number of lines of code possible. I can do this because there is only 1 other programmer here, and I know he's not going to screw it up.

I don't know your situation, obviously, but my initial reaction is... "Holy crap man... run!"
"I was stuck in a prison of Microsoft Operating Systems, and I have been released."
"if you're in a company where the other programmers are top notch"

I've never seen such a thing (and I've seen alot).

Reason #127 for starting your own.
Where'd you ever get the idea that there is any trade-off between "quick" and "right"?

I don't have that idea. There is sometimes, though, a tradeoff between current needs and future needs; and that tradeoff can not always be predicted. When that happens, it's logical to give current demands priority.

I can't for example, predict whether a future maintainer of my code would prefer code written with multiple returns, or code that sets temporary values, or code that uses a set of nested ifs, or code that assigns function pointers to a matrix and calls code based on the indices. Each technique has potential drawbackss in terms of future maintainability, likelihood of errors, and speed of immediate implementation. Trying to guess what a future coder (other than myself) will think is just not important in that case.

Effective Principles can only be Established based on a given development environment, and it's the responsibility of those in charge of the environment to make sure the established principles are effective and followed by the developers.
That's why "return" (and "throw" and "assert") is syntax-highlighted in most editors. ;-)

Honestly, I've never had a case where I visually missed an early exit. Most of the time, such exits are guard statements, designed to bail out with an exception if some precondition isn't met. Most of the rest, they're "found it, don't need to do any more processing" and apparent from the logic. I'll usually mark the latter with a quick comment anyway, just to be sure I don't miss them.

And early returns let you apply additional invariants to your code. You've checked your preconditions and bailed if necessary; you don't need to worry that this array might be null. You've handled the 1-item base case; you don't need to worry about your recursive function blowing up. I find that broken invariants cause many, many more bugs than missing an exit and not executing code.
"15 different programmers are rarely touching the same piece of code over any short or medium span of time"

I see it all the time. But then again, maybe I'm like the blind man with the elephant; I only know what I've encountered.

Wouldn't it be great if analysis was conducted properly, design specs were tight, functional specs were accurate, projects were managed properly, programmers were trained, resources were adequate, and the people paying the bills had a clue as to what they needed? I've never seen it. That may be why code gets modified so many times. I've even seen "quick & dirty" temporary programs still in production for 15 years. This is the world we have to deal with. That's why we adhere to structured programming principles: to save ourselves a whole lot of trouble down the road.
Conway's Law (A software system will resemble the organization that built it)
I heard this principle a few times and finally tracked down the original 1968 paper. One can point out several applications of his idea. For example, large, hierarchical organizations whose parts don't work well together tend to produce large, hierarchical software systems whose parts don't work well together.
I usually follow the childhood adage "First time it's funny, second time it's silly, third time's a spanking." Probably better summed up as http://www.c2.com/cgi/wiki?ThreeStrikesAndYouRefactor. Problem is, after 2 repetitions you often don't know what the real abstraction behind the duplicated code is, and so you end up with convoluted objects or closures to swap out parts of behavior, while there's a more natural abstraction just around the corner. If you mercilessly refactor after only the first duplication, you might not see it after the second, because the original code has been abstracted enough that it doesn't look like the third repetition.

This also squares with a lot of IBM's experience in The Mythical Man Month, i.e. code needs at least three clients to really be reusable.
A few clarifications: Canada is generally a country where the concept of "employment at will" does not exist. You want to fire someone? You need to pay severance. We also have human rights legislation that can add to what you must pay if you fire someone who is older, pregnant or has one of a wide range of conditions that can be deemed a disability (drug addiction, alcoholism, depression). There are penalties payable for toxic work places or for firing in a particularly harsh manner. These are many reasons why employers based in the US tend to dislike Canadian employment laws - if you hire the wrong person, you have to pay to get rid of them.

Onto the stickiness issue - you're generally right - there is great R&D talent in Ottawa, for example, but very few superstar tech companies at the moment. If you are like most R&D talent and attracted by the quality of work, you're pretty sticky.

A related point - thanks to the limited number ofwork Visas to the US, we've become a naturally sticky country for near-shoring talent from India, etc that cannot get a permit to work in the valley. Sticky by geography works for us, too.
Are the costs of function call overhead worth worrying about?
Microsoft does do this. You have to prove you're a real software startup and then they give you basically everything for a nominal price. But I don't agree that the presence or lack of such a program is the reason why most startups don't base themselves on MS.
The Java API's are wildly inconsistent. Some are pretty good, but some (Calendar, Date, IO) are massive trainwrecks that even some of Java's architects don't like. Joshua Bloch gave a presentation somewhere on effective API design where he ragged on Calendar.

And the Design Patterns and Refactoring should be considered starting points, not the be-all-and-end-all of programming. Every programmer should be familiar with them just for the vocabulary. But there are better examples of programming in SICP, On Lisp, Programming Pearls, and TeX: The Program.
That's what the other rule is for, to not make functions span too many lines ;-)
Maybe this is the crux of Dijkstra's original arguments.

Which is more expensive, a few milliseconds of machine time a few million times or a whole bunch of human time once or twice?
Not at all. What I meant was, you're calling the function in two places, instead of in one place (inside the loop). You've pasted that function call. Thus, by all the same logic, you are introducing a possible future headache.
There aren't new concepts, just actual explanations of what the presentation is talking about.

"I'd use the presentation as a way of glossing over the high points, and then refer somebody to your link as a way of figuring out how it all works."

Probably a good strategy.
"I've never had a case where I visually missed an early exit."

Too bad the same's not true for those I have followed. And when it does happen, it makes the worst kind of mess - the kind you don't discover until 6 months later.

Guidelines and rules are not meant for the best of us; we don't need them as much. They're meant for the mediocre masses who are everywhere and wouldn't know any better.
That's super gay. I don't download or distribute P2P content, but still.
That's a pretty old article.
My examples and suggestions are limited for Java/C#. The reason why I pointed out Java API is such that people can see which part has a good clean code and which part has inconsistent design.

I'm not currently programming in functional language so I can't really say how much SICP and On Lisp help people to write better software. To my understanding, despite the praise of LISP for clean code, the statement mostly come from experience developers with years of flight-time. I began to question whether LISP actually helped them much given their extensive experience.

Paul Graham (or insert any bloggers that praised LISP) said LISP helped him code in a better way (and etc etc etc) but Paul Graham never program in Java so how do we know if his LISP experience actually help the way he programs in OOP?

Other experience developers said Scheme helped them to have clean code but then again, they threw that statement after x-number of projects in which I'm sure they've learned a lot anyway.
I'll know it when I maintain it.
reason #1 to get a new job. You might have seen a "lot", but you've seen a lot of the wrong thing.
If your programmers were a) competent or b) wrote tests this wouldnt happen. If they're not competent and don't write tests they should be fired.
Not quite a bad sign. Maybe they're just happy at the place they're working and the employees are loyal people.
Why would you want to be a loyal employee?
Agreed.

Cue the blame-the-programmer-for-not-being-smart-enough comments.

Guys. The goal isn't to provide the "perfect" code that somehow those poor average schmucks just can't understand. The goal is to provide the dumbest, easiest-to-follow narrative of how the computer is going to solve the problem for the user so that the next guy is able to understand it.