ID:265872
 Nov 6 2008, 7:08 pm (Edited on May 30 2009, 11:58 pm)
|
|
It's less whitespace to chew vs other tokens for { }. The gains really are very slight, if at all, as you said.
| |
It greatly reduces vertical scrolling - if the function is obvious, I have no issue one-lining it.
But for most things it's pointless. | |
Pros:
- Makes you feel l33t because you can compact your code like that. - Gives you an edge when competing in 4k competitions. - Keeps people from making improvements on stolen source code. Cons: - Makes your code difficult to read and understand. - Makes problems in your code much more difficult to locate. - Makes it harder to make changes to your code. - Makes you look like a n00b. - No put usr in proc. Ungh. - Takes up too much horizontal space. - Makes errors harder to find by line number. - Doesn't leave room for useful comments. | |
Note that Login() is often usr-safe (you should still use src, but unless you're doing character handling, it's fine), and Click() is always usr-safe unless you do something ridiculous like call it manually.
| |
Foomer wrote:
Pros: liek omg! that wat i was totaly goin 4! Anyways, thanks. | |
Cons:
-Wow, separate vars for dead and alive? That's brilliant, who came up with that idea? >_> <font size=1><small>(even though it was an example)</small></font> | |
Kaioken wrote:
Cons: Perhaps one can be dead and alive at once. Even so, better done with bitflags! | |
Pro: It makes your most likely already pretty small DMB a little smaller (which, like Foomer said, is useful in 4k contests).
| |
Jeff8500 wrote:
Pro: It makes your most likely already pretty small DMB a little smaller (which, like Foomer said, is useful in 4k contests). It makes the .dm files smaller. I don't think it makes any difference to the .dmb. | |
The code is compiled into the virtually same result in both instances, the size difference between the different notations (as that's what they are), most likely does not exist.
And the 4k contest isn't about having a DMB smaller than 4k, or you couldn't used much resources (and could use a lot more code). The size limit is for your source code itself, which is why using obnoxiously short code is beneficial to begin with. | |
Kaioken wrote:
And the 4k contest isn't about having a DMB smaller than 4k Be cooler if it were, though. Resources are stored in the RSC - the DMB is just compiled code. As it is, 4k is more about who makes the most compressed source code, not who can code the best stuff in the least amount of space. If the restriction were imposed on the DMB instead, then people could create source code that's actually readable and full of comments while still striving to be under the 4k limit. But this is totally off topic. | |
Xooxer wrote:
A new project with no code compiles to 6.51K. It would have to be 7 or 8K. That would be fine too. Although, looking at how much code actually goes into a DMB, I'm thinking 12-24k would be more practical for anything more than tic-tac-toe. | |
Foomer wrote:
Be cooler if it were, though. Resources are stored in the RSC - the DMB is just compiled code. Yeah, I was referring to them together in my mind, oops. Though, without counting the RSC still, you wouldn't be able to have a big map if you wanted. =P As it is, 4k is more about who makes the most compressed source code, not who can code the best stuff in the least amount of space. But the games are judged to see which's the best, so how is it about whose the most compressed? You need to have it compressed just to enter. Anyway, making compressed code is kinda the point of the contest too, and the DMB's size might change too arbitrarily by different kinds of instructions compiled into it, which may not be so fair. If the restriction were imposed on the DMB instead, then people could create source code that's actually readable and full of comments while still striving to be under the 4k limit. Well, you could try and write the game 'normally' at the beginning, and compress it after you're done, while still keeping the 'normal' version for non-contest development and release. Probably some people have done this. But this is totally off topic. _> Just a little. | |
- ???
- Very slightly speeds up compile times ... I guess?
Cons:
- Harms construct readability.
- Harms the ability of the reader to follow the flow of logic.
- The usefulness of line numbers for error messages is seriously eroded.
- Harms readability.
- Harms ... readability.
You're essentially obfuscating the code for no apparent reason.