|
This is some humble advice on how I believe people should deal with bad code. It’s not technical advice. Actually it’s not really advice. It’s just stuff I’ve been thinking of lately. Typically, the first thing a person does when encountering bad code is determining who they should blame. Immediately it becomes a personal or tribal vendetta. This is wrong. This should not be the first step. A deeper understanding of the code is necessary before we identify the poor soul who should suffer your wrath. Admit it: You could have written code this bad. It’s not beneath you.
|
|
|
|
|
Probably the most controversial part of PEP 8 is the limit of 80 characters per line. Well, is actually 79 chars, but I’ll use 80 chars because is a round number and the way everybody referes to it.... It seems that, naturally, Python code tends to occupy around 35-60 characters (without indentation). Longer lines than that are much less frequent. Having suddenly a line much longer than the rest feels strange and somehow ugly.... So, even if the initial intention probably has little to do with all those things, I really feel that this limitation helps me writing more readable and compact code. I am sort of a “readability” integrist, in the way that I feel that readability in the code is the most important consideration by default, and should be keeping in mind at all times. Could you code effectively with an 80-character line limit today?
|
|
|
|
|
Terrence Dorsey wrote: Could you code effectively with an 80-character line limit today?
I only code with this width in mind, as I often use the terminal on Linux. I thought pretty much anyone who wrote over this width just broke it down into a multi-line statement anyway 
=====
\ | /
\|/
|
|-----|
| |
|_ |
_) | /
_) __/_
_) ____
| /|
| / |
| |
|-----|
|
=====
===
=
|
|
|
|
|
Quote: I thought pretty much anyone who wrote over this width just broke it down into a multi-line statement anyway
Sadly, no. I've seen some pretty hairy-long lines. It's not pretty.
I spent many years re-formatting for print layout with more or less 80-column width, so the habit in hard-coded in my brain now.
Lately I've been messing about quite a bit in Xcode, and discovered that it does a pretty nice job of auto-formatting and indenting line breaks in a sensible, readable manner. Message parameters stack up nicely, etc. Still learning to trust it and anticipate what's likely to happen in a given situation, but the defaults do seem to lend themselves to compact, readable code.
Director of Content Development, The Code Project
|
|
|
|
|
I could code within 80 character, but do not. I am not sure what I code to, but i do not like it when code falls off the screen, and I don't like the wrapping either. All my XAML is not one attribute per line, but I did not start that way. Part of the coding standard I had to use at Microsoft, and after that started doing it that way. I tend to like to have my code compact, so I do not have many blank lines, and I will put return statements on the same line as an if statement, and keep properties to a minimum number of lines if I can.
|
|
|
|
|
I used to. We had VT100s in college. Then it was in the company standard. Even though the VT420s we were using at the time allowed for 132 characters per line (as do VT220s and newer), the PRO*C precompiler defaulted to 80 characters and the powers that were said we would abide by it.
For my own coding I stick to 112 characters because that's how many 8pt Andale Mono characters I can fit in 7.5"
|
|
|
|
|
PIEBALDconsult wrote: For my own coding I stick to 112 characters
Me too, because I often view 2 files (or 2 views of the same file) in portrait mode in VS.
/ravi
|
|
|
|
|
I generally code in ~120.
I have VS set to draw lines at 80, 120, and 160. IntelliJ has one line at 120, Eclipse doesn't have any at all. I'm not sure if the latter two are adjustable, I don't do enough java to have bothered looking for options to change them (or if I did I forgot about doing so).
My edit pane is currently 146 chars wide, but that changes somewhat depending on what I'm doing in sidebars. Really long lines tend to be noxiously long type names (auto generated xml classes are among the worst), places where I need to drill deeply into object hierarchies, and linq queries where there's no good natural spot to break the line. Otherwise most of my lines are under 80 chars; some of the ugly lines do end up longer because there's still nowhere to break the line that doesn't turn out to be breaking a line just for the sake of breaking a line and I'd rather scroll because arbitrary stupid line breaks are even more disruptive.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
It's tough these days depending on the language to stay under 80 characters per line. There are two main reasons:
One, the nested constructs and the way they are formatted in languages like C#. You have namespaces, classes, methods, closures, etc. Again, this is language dependent, but some of these constructs in some languages carry with them a level of indention, so you can go several layers deep before actually getting to implementation code. At that point, a good many of those 80 characters have already been eaten.
A second reason is the practice of using readable identifiers, e.g. method and variable names. These add to the character count per line (not saying we should abandon them in exchange for cryptic names, though).
|
|
|
|
|
Is it possible to rank programming languages by their efficiency, or expressiveness? In other words, can you compare how simply you can express a concept in them? One proxy for this is how many lines of code change in each commit. This would provide a view into how expressive each language enables you to be in the same amount of space. Because the number of bugs in code is proportional to the number of source lines, not the number of ideas expressed, a more expressive language is always worth considering for that reason alone. Bottom line: Clojure and CoffeeScript win.
|
|
|
|
|
An average of ~900 lines per C# checkin??? I think the only times I've ever hit that high have been when I was checking in auto generated xml/database wrapper classes or the initial .designer.cs files for dialogs.
Are these numbers being biased by massive codebases where even a trivial refactor hits a massive number of changes, or are people really checking in an entire weeks worth of work at once?!?!
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
The wording is a bit unfortunate here. Online repositories use a DVCS like Git, where even if you checkin often it is still on your local machine. Every now and then you push to the server (which in this case is somewhat incorrectly referred to as checkin, at least that's what I assume), which basically is a bulk checkin, as it preserves your local checkin history, yet from the outside it looks like one major checkin. So bottom line is that there is a difference between commits (local checkin) and pushes (remote checkin).
|
|
|
|
|
My journey into the Dark-ish Side began during a chat with our security editor, Dan Goodin, who remarked in an offhand fashion that cracking passwords was approaching entry-level "script kiddie stuff." This got me thinking, because—though I understand password cracking conceptually—I can't hack my way out of the proverbial paper bag. I'm the very definition of a "script kiddie," someone who needs the simplified and automated tools created by others to mount attacks that he couldn't manage if left to his own devices.... It sounded like an interesting challenge. Cracking so many passwords so easily led me to one final question: how secure were my own key passwords?
|
|
|
|
|
i love crackers! only the one with salt though
|
|
|
|
|
We already know that Internet Explorer 11, the next iteration of the world's most popular browser, will include tab syncing as part of the Windows Blue update, which has leaked onto the Internet. Neowin has also discovered that IE11 will include new code which tells the host website that IE is, in fact, Firefox. Some websites serve certain versions of Internet Explorer (we're looking at you, 6) with custom CSS code in order to make sure the website displays in a readable way. These practices are known as "CSS hacks" and target IE6, 7, 8 with a different type of CSS code than other browsers, such as Chrome and Firefox. Will this be IE11's most useful feature?
|
|
|
|
|
The most courageous politician in California — probably the nation — is a Berkeley city councilman, Gordon Wozniak. His gutsy act: proposing that the government tax email. Yes, sacrosanct, time-gobbling, out-of-control email.... Here's how I'd set it up: Emailing within a company would be tax-free. I'd allow everyone a certain number of untaxed, private emails a month — 100, maybe 200. After that, each message would cost one cent, up to a certain size. If they ran off the screen, they'd cost extra — just as a bulky letter costs more than a 46-cent stamp. After 500 emails, the fare would be hiked to 2 cents to discourage the junk-mailers. Copy 500 people on one message, that's 500 emails. Coin-op inbox.
|
|
|
|
|
Windows Blue made an early appearance on the internet over the weekend and we've had a chance to experience some of its new features. The upgrade to Windows 8 looks like it's going to bring a host of improvements, fixes, and some new built-in apps too, but the biggest changes are on the UI side. Microsoft now supports smaller Live Tiles and the company is changing the way you arrange them on the Start Screen. Moving ever closer to Windows Phone, you can pick between large, medium, and small Live Tiles for applications. More SkyDrive. More MovieMaker? More Charms?
|
|
|
|
|
and no Start Menu!
What's even more amazing we have Windows 2012 Server the same limitation exist there, no Start Menu is a nightmare on a Server to say the least.
|
|
|
|
|
>no Start Menu is a nightmare on a Server to say the least.<
Ha Ha, you should try the Core version(s). It's command line only. 
In the end, it all depends on the server roles you intend to use. Harder to configure but not impossible, with scripted setup.
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
|
|
|
|
|
|
Sometimes life is much stranger than fiction.
Some of the stuff we've read about in the last couple of years like Stuxnet, Duqu, and that decade-old cyber-espionage, is just scary. If the premise of those attacks weren't military/political, just think how many of us could have our lives compromised in a flash. What if that type of organized attack targets a city's infrastructure? Or make a wide-spread coordinated attack on police response using the same principle as used against the author?
Just scary.
-EM
|
|
|
|
|
When everyone else is trying to automate everything, using a little human intervention can be a competitive advantage. The problem is when business owners see it as a cost, instead of an opportunity. Trying to minimize costs, instead of maximize income, quality, loyalty, happiness, connection, and all those other wonderful things that come from real human attention. It’s fun to try to find the tech solution to everything, but a real person can be the best alogrithm.
|
|
|
|
|
As developers, we often find ourselves under a lot of pressure to crank out code and copy then paste it somewhere else in a solution and make a slight modification here and there and get the product out the door. It's a frequent occurrence and hence the number of lines of code is not a great measure of quality code. There's nothing wrong if it gets the code out the door, however, when we have time we can go back and fix this. What happens, if we don't and some code has been copied and pasted in different renditions and a bug comes up in one of the scenarios? Code Clone Analysis in Visual Studio 2012 is your friend.
|
|
|
|
|
Decoupling your application from the details provides you with the ability to defer implementation decisions until you have a clearer picture of what you really need. In addition, decoupling has the added benefit of making it easier to test your system. In this post I want to take a closer look the Repository Pattern as a way that we can decouple ourselves from one of those details: the database. It's just an interface (on an interface... on an interface....)
|
|
|
|
|
Flustered by so much JavaScript? Concerned with all the seemingly new patterns to learn? Confused about how to organize it? You are not alone. Let me put it another way: if you work on a ASP.NET MVC project take a look at all of the dll’s in your references folder. How many is too many there? I bet they don’t bother most folks. Rarely do I hear complaints about that. Is it because Microsoft put them there? Or is it because they are out of sight out of mind? Or possibly we are just used to them being there. Now let’s take a look at the 3rd party JavaScript libraries... If a library offers more value than me writing it, then I am fine using it.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
