Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - IsmAvatar

616
Announcements / Re: Shortcuts
« on: July 29, 2010, 01:26:45 pm »
Your intricate new posts are too intricate for many of us to follow.

I think you'd be lucky if most of the people here are able to gather from it that you are introducing foreach into the language.

617
Issues Help Desk / Re: screw angle()
« on: July 25, 2010, 12:41:22 pm »
Quote
It fits a number within a range.
Code: [Select]
if (value < min) return min; if (value > max) return max; return value;
Code: [Select]
return value < min ? min : (value > max ? max : value);

618
Issues Help Desk / Re: GL Lighting
« on: July 25, 2010, 12:17:37 am »
You're welcome to submit your own proposals, but your format is inconsistent at best, making it hard to write formatting rules for.

That said, you're obviously allowed to use your coding style and never use the formatter.

619
Issues Help Desk / Re: screw angle()
« on: July 24, 2010, 10:38:28 pm »
It might help if we knew exactly what the function was supposed to do and how it is expected to behave on negative numbers.

620
Issues Help Desk / Re: GL Lighting
« on: July 24, 2010, 06:01:02 pm »
Well my hair is a bird, so your argument is invalid.

621
Issues Help Desk / Re: screw angle()
« on: July 24, 2010, 05:59:56 pm »
fmod can be used to bring a negative number into the negative range. After that, you simply add the range to mod it into positive if desired.

Pardon the handwaving, I haven't worked the math out in my head yet.

622
Issues Help Desk / Re: GL Lighting
« on: July 24, 2010, 11:01:38 am »
I thought you were referring to my other method, which I use for Java.

I use that method for C and GML simply because I'm trying to save vertical space because the IDEs I use don't have good ways of saving vertical space for me, like Eclipse does.

623
Proposals / Re: Steam
« on: July 24, 2010, 08:56:28 am »
If it's C/C++, or a DLL, then yes. Before compiling, of course.

624
Issues Help Desk / Re: GL Lighting
« on: July 23, 2010, 10:58:59 pm »
The braces are aligned.

625
Issues Help Desk / Re: GL Lighting
« on: July 23, 2010, 06:20:00 pm »
Quote
Ism, I hate your method worse. :/
At least my method has some logic behind it.

626
Proposals / Re: Code Formatting
« on: July 23, 2010, 06:17:09 pm »
There will be no voting, and the second option will not be omitted as false. These are options which are user preferences, meaning that each user will select their desired formatting style from a preferences frame with checkboxes/such. Formatting will only be applied if the user then chooses to format their code. If you get someone else's code and don't like their formatting, you may simply pass it through the formatter with your preferences passed in (which will be remembered between uses).

Quote
And other tedious things, such as spaces between operators and if() vs. if ()
Although options could be made of these, I think for now some of these could just be included in the formatter by default. Unless I'm mistaken, I think most people prefer to see "if ()".

If they are made options, we should word them.
Here's my attempt at wording these options:

* Spacing after if/while/etc
Code: [Select]
if(true)
Code: [Select]
if (true) (does anybody really use False here?)


* Spacing between beginning parenthesis and contents
Code: [Select]
(false)
Code: [Select]
( true) (does anybody really use True here?)

* Spacing between ending parenthesis and contents
Code: [Select]
(false)
Code: [Select]
(true ) (does anybody really use True here?)

** Combined:
Code: [Select]
( true && true )

* Spacing between each argument (after comma)
Code: [Select]
run(false,false)
Code: [Select]
run(true, true)
* Spacing around operators
Code: [Select]
(false|false)
Code: [Select]
(true|true)

627
Proposals / Code Formatting
« on: July 23, 2010, 08:10:10 am »
Not to sound lazy, but LGM could really use a code formatter, and since ENIGMA already has a parser, it seems like it'd be a lot easier for ENIGMA to serve that purpose than LGM. Obviously there'd be a few options to specify the format. Right now I think a simple set of post-conditional indentation controls to be the bare essentials.

1) Place first curly bracket on newline?
2) Indent curly bracket(s)?

Needless to say, the code inside the curly brackets would be indented properly without needing to specify an option at this point.

Original heap of junk:
Code: [Select]
if(blah){doThis();}
false false:
Code: [Select]
if (blah) {
  doThis();
}

false true:
Code: [Select]
if (blah) {
  doThis();
  }

true false:
Code: [Select]
if (blah)
{
  doThis();
}

true true:
Code: [Select]
if (blah)
  {
  doThis();
  }

628
Issues Help Desk / Re: GL Lighting
« on: July 23, 2010, 08:02:19 am »
Oh god, I hate that.

629
Issues Help Desk / Re: GL Lighting
« on: July 22, 2010, 02:15:40 pm »
Quote
Almost every programmer that I know codes like the first one except for the ones here.
I code like the first one. See LateralGM. In C and GML, I usually code like this, though:

Code: [Select]
while (doSomething()) {
  doSomethingElse();
}

630
Issues Help Desk / Re: GL Lighting
« on: July 22, 2010, 10:22:52 am »
I'm with him. Indentation belongs to the block that follows the conditional. Very much like indentation-based languages, like Python. You indent every line belonging to the conditional. For example, consider if you wrote it without the block brackets. You'd still indent the line.