|
I've been playing around with some web stuff, and getting irritated with Aptana's auto tag closing acting funny if you add an attribute before ending the opening tag (e.g. type "<div class="cls">" end up with "<div class="cls">></div>", an extra ">" than I wanted). This looks like an easy way around that, and the added benefit of less typing. Have to try it out when I get home. 
|
|
|
|
|
|
And they are already giving hints... Clickety[^]
|
|
|
|
|
That is actually kinda cool.
Gryphons Are Awesome! Gryphons Are Awesome!
|
|
|
|
|
It's a lot of fuss over what is basically Windows 8 Service Pack 2.
=====
\ | /
\|/
|
|-----|
| |
|_ |
_) | /
_) __/_
_) ____
| /|
| / |
| |
|-----|
|
=====
===
=
|
|
|
|
|
Lloyd Atkinson wrote: It's a lot of fuss over what is basically Windows 8 Service Pack 2.
It's a big deal for those of us running 8 and missing those features.
|
|
|
|
|
An invalid time?! Since when is 1am on March 31 an invalid time? I mean it’s not like it’s November 31 or February 29 on a non-leap year, what an earth is wrong with this time?! And for that matter, how on earth do you get an error when converting GMT to UTC, isn’t it the same thing?! The problem is that 1am on March 31 this year simply will not exist in the time zone above; people there will literally travel through time! The other problem is that GMT isn’t UTC – but it’s close. Spring forward. Fall back. Abort. Retry. Cancel.
|
|
|
|
|
Just a question, how did you try to do this, C#. I know I am not real thrilled that there is no specific data and time formats. I understand the need for a datetime format, but there are many times that adding the extra information just makes the developer's life harder. Finally got around to creating them in SQL-Server several years ago. Not sure I disagree with taking into account the stupid time change due to daylight savings time. Doing the time change in the first place is dangerous (http://stress.about.com/b/2012/03/11/the-dangers-of-daylight-saving-time.htm[^]). Also, obviously it can be a pain in the neck for a developer.
|
|
|
|
|
Don't get me started on Daylight Saving Time. As soon as I finish building my time machine, I will erase this horrible idea from history. I just need to determine if I have to pay a visit to Ben Franklin, George Vernon Hudson or William Willett[^]. 
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
Interesting.
00,00 GMT Standard Time (Fails)
00,00 Greenwich Standard Time (Passes).
Aren't they one and the same?
Code Snippet:
DateTime dtSourceDateTime = new DateTime(2013, 3, 31, 1, 0, 0);
TimeZoneInfo objTimeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
Console.WriteLine(TimeZoneInfo.ConvertTimeToUtc(dtSourceDateTime, objTimeZoneInfo).ToString("MM/dd/yyyy HH:mm"));
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep!
|
|
|
|
|
One of the things that have annoyed me about Visual Studio for many years, is the inconsistency when pasting code copied from websites. Depending on the browser you get different results.... So, in a rare moment of clarity a few days ago, I decided to fix this issue by writing an extension for Visual Studio - Pretty Paste. The idea is to inject some logic just before the regular Paste command in VS executes. That logic will quickly analyze the text being pasted and correct any non-intended line numbers and extra blank lines. Copy-paste programming made easier - and prettier - in Visual Studio.
|
|
|
|
|
When it came to outreach, we went bigger than ever by reaching down to the little ones: children. For the first time, we offered two days of free tutorials for kids, titled “The Young Coder: Let’s Learn Python”.... “I don't think you'd ever see that kind of experimentation in a classroom full of adults, who would more likely do everything in their power not to break their computers,” Barbara wrote of the kids’ ability to learn, write, and run code that quickly bogged the machine down. Shortly into the course, they learned to write their name in a string and then multiply it by huge numbers. If they went too far, a simple unplug and re-plug brought them back to square one. Great ideas for teaching kids programming from a successful event.
|
|
|
|
|
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?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
