Is better to code
1. In a way can be readable easily on first sight but maybe inefficient
or
2. That is very efficient and short but more complicated to read and understand
My instructor (a very scary prof) always tells us to go to option #1. Yes you can still do option #2 if you provider enough comments to explain.
But if you do option #1, you will not need to comment alot about your code because your code will speak for itself because of its easy readability.
What do you think?
Name:
Anonymous2006-02-15 20:32
Stick with #1, unless it's a piece of code you need as optimized as theoretically possible (written in assembler, of course).
When you are working on a proc/func that does something complicated and unique (to optimize performance), use #2, but comment the algorithm and provide the same proc/func in the format of #1.
Name:
Anonymous2006-02-15 21:02
#1 is better.
Name:
Anonymous2006-02-15 21:11
Again go with #1 unless you're doing something critical. Unless you're coding for an one time use thing, what you write will need to be maintained.
Name:
Anonymous2006-02-15 22:08
#1 all the way, unless you have damn good reason.
Name:
Anonymous2006-02-16 3:49
Even if you do need it optimized, do #1 first then when it's working properly comment it out and rewrite as #2.
I'd also suggest moving "short" from #2 to #1 since if there's less to read it's easier; conversely optimizing often requires abandoning high level abstractions and writing out a long block of ugly statements.
Name:
Anonymous2006-02-16 7:39
I'd take a middle ground most of the times.
For scripts, sometimes it's a pain to comment, but for moderately complex scripts (>4 KB) I make sure to comment all of it very nicely because if I ever need to do something to it it'll save enough time to make it worth.
For applications that are not time/speed critical, I usually do #1, but my algorithms are usually optimized enough (even if this makes them slightly less obvious), and I provide lots and lots of comment on them.
For system applications (tools, kernel, etc.), games, and applications that are time/speed critical, I usually go #2, while still commenting what I'm doing.
>>2 said something I agree with - to optimize standalone algorithms and comment them as a block, basically. I do this sometimes, but not if they get too large.
Name:
Anonymous2006-02-16 9:49
Go for #1, and if you have to do #2 make sure its properly commented if you feel like you ever want to understand it again :)
Name:
Anonymous2006-02-16 13:19
always #1, then #2 if needed, because your super-duper-hyper-engineered code might not have been needed anyway.
Name:
Anonymous2006-02-16 17:40
because your super-duper-hyper-engineered code might not have been needed anyway.
Signed, signed, and signed again.
Besides, I find it totally hilarious how often new programmers go hog wild with data structures with low time complexity. Newsflash guys: quite often the simple yet slow algorithm is a lot faster if you're only dealing with a few elements.
It's like using a rocket launcher to kill a squirrel: total overkill, and really heavy too.
I grade a lot of C++ homework for my uni, and I usually see a bunch of failed attempts at #2. (like >>10 said - overkill)
I also do freelance programming and I have to work with a ton of poorly written attempts at #2 (with no comments and variables in fucking german) and I feel like stabbing the hell out of the previous developer. Seriously, do your fellow programmer a favor and just stick to neatness. *twitch*
Name:
Anonymous2006-02-19 4:21
>>12
agreed. comment comment comment. irregardless of how stupid it reads at the time.
Name:
Anonymous2006-02-19 7:01
Irregardless, with its illogical negative prefix, is widely heard, perhaps arising under the influence of such perfectly correct forms as: irrespective. Irregardless is avoided by careful users of English. Use regardless to mean 'without regard or consideration for' or 'nevertheless'.
Name:
Anonymous2006-02-19 12:25
I tried #2 at work. Five hours later my boss taps me on the shoulder says "I know you're knew, so I won't rape you for this - but you reeeeaally don't need to spend that much time optimizing this. If I need you to do that, I will tell you explicitly." This holds up pretty generally I think.
Name:
Anonymous2006-02-19 14:18
>>11
You mean the code or the squirrel killing? Because squirrel + exploding rocket = oh yes.
>>15
At least you're not trying to jam every single framework you've seen in. :D
>>17
The points on using simple selectors and letting cascading work its magic and the like is kind of like OO theory. You want to group the common tasks in abstract classes and inherit from
Cutting the comments, removing names spaces and using short class/ID names is dumb though. Any browser that supports CSS will probably request the web server to compress all plain text mimetypes anyhow.
Name:
Anonymous2006-02-20 6:05
>>17
This article is not that bad at all. In fact, I agree with most of it, only adding that class name shortening, whitespace and comments removal, and color shortening should be performed:
- Not in the original files
- In the production files
- By a script
This is what some sites like Google do to be that fast. Have a look at Google's HTML and JavaScript.
Name:
Anonymous2006-02-25 7:58
You do #1, then you follow the rules of optimization:
>>20
Well, google still uses tables and stuff for no apparent reason. Maybe they really do need to support incredibly old browsers, but that doesn't explain why new ones get old crappy HTML even though their pages would get even smaller.
Name:
Anonymous2006-02-25 15:52 (sage)
>>23
Because that is what works for them. Why can those semantic HTML zealots manage to sneak into every fucking debate?
Name:
Anonymous2006-02-27 4:15
Semantics semantics LOL!
HTML would need 10 times more tags if we were to get to any decent semantics standards. Anyways, who the fuck cares for semantics? You're not to read HTML yourself, it's your browser what does, so it might as well be a binary format. In fact, when it came out, I was so pissed at the 25% bandwidth wastage for not being binary.
Thats why i hate HTML. I can't freaking code it nicely to be readable in code form (tabs etc). Ends up i have to reaarrange it so it looks rite on the browser but makes my eyes go blind each time i read the actual code.
And dun tell me to go use a WYSIWYG editor (dreamweaver), some HTML files like themes files etc etc but be edited in code since they dun render at all on a WYSISWYG editor.
XHTML + CSS makes it a lot easier to edit HTML. Seperation of style from content ftw.
Name:
Anonymous2006-02-27 23:26
does anyone know why opera is slow to load webpages?
especially ones using css...
Name:
Anonymous2006-02-28 0:10
>>30
It loads everything faster for me (using 8.51) on a mid-range connection. But if you're on a particularly fast connection, try the following:
* go to preferences->advances->browsing and meddle with the "Loading" dropdown
* go to preferences->advanced->networking, and check the max/max connections dropdowns.
Name:
Anonymous2006-02-28 2:42
>>30
use opera version beyond 3 (hint: we're on 8.52 now)
Human readable (for maintenance), possibly optimized before production theme files (CSS + application templates) with optimal dynamically generated contents for the win.
Name:
Anonymous2006-02-28 5:08
>>32
I was on 8.0 :((((((((( >>31
after the update to 8.2, it sped up even more thanks.
So now I see this FOUC effect because it loads so fast! what can you do to prevent this? like how can you make sure your css loads and formats everything before actually displaying the page regardless of browser?
Name:
Anonymous2006-02-28 5:52
FOUC effect
You mean the reflow? Why would you want to disable that? That's there so you can read slow-loading pages before they're ready.
But if you do, I've already pointed out how: meddle with the Loading dropdown. Try setting it to "Redraw when done". It'll take longer to display something, but FOUC should be gone.
Name:
Anonymous2006-02-28 15:01
like how can you make sure your css loads and formats everything before actually displaying the page regardless of browser?
you could put "body{display:none}" in a style tag in the html file and then put "body{display:inline}" in your stylesheet and make sure the link tag for the stylesheet is after the style tag...
Name:
Anonymous2006-02-28 15:16
>>37
one small problem...
it doesn't work in plain html in gecko, and if you send as application/xhtml+xml IE doesn't like it...
there are ways of hacking around this stupidity, like sending the page as application/xml or text/xml and using xslt to get IE to render it as html...
Name:
Anonymous2009-03-06 8:24
selectors for a data structure that can be implemented as a table or div What would the benefit be.