[vwnc] Code Formatting

>
> On Mar 1, 2008, at 12:06 AM, Antony Blakey wrote:
>>
>> At the risk of being flamed: IMHO the general casting of choice as a
>> moral good is a fallacy - one that can most obviously been seen in
>> the enormous configurability of ugly and unusable open source GUI
>> software vs. the highly constrained and usable OSX environment.
>
>
> It seemed to me that Travis was attacking exactly this aspect of the
> formatter (too many options) rather than its aesthetics.

> Travis,
>
> Here are the options I'd look for:
>
> Indent one tab per for each multi-line nested block. The block  
> starting
> bracket is the last token on the statement line that began it. The  
> block
> ending bracket is in visual alignment with the start of the statement
> that began the block. Use periods for all statements except statements
> that return from the method. All cascaded messages (that can't fit  
> on a
> single line) should be intended one level from the receiver. When the
> receiver of cascaded message is the result of a unary message then
> enclose receiver code in (). Don't automatically add # to symbols  
> within
> literal arrays.
>
> Here are some benefits from these preferences:
>
> This style is familiar to developers who use other languages. Code
> changes are easily shown--because the code formatting is not radically
> affected by the addition or removal of code. Code is easily copied and
> pasted as lines between methods. It isn't necessary to double-click to
> discover the end of contexts. File-based change management tools (like
> cvs) can resolve differences better. With "unnecessary" periods, you
> have fewer MNU errors because someone forgot to add a period to the
> statement that they added code below; it also means the period is  
> not a
> change shown later in the changes browser. Less scrolling is involved
> because more logic fits nicely within a standard size code pane.
>
> When code is formatted is just as important as how it is formatted:
>
> Code can be saved formatted according to a company standard. Code  
> can be
> displayed in browsers according to individual formatting preferences.
> Code should be formatted consistently in all panes of a changes  
> browser.
> Formatting should be an option that can be easily turned off--
> sometimes
> even as a check box on an individual browser.
>
> Paul Baumann
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Travis Griggs
> Sent: Friday, February 29, 2008 3:11 PM
> To: VWNC List; VW-Dev DEV
> Subject: [vwnc] Code Formatting
>
> I've been playing with handling comments better in the RBParser/
> Formatter. I haven't actually done much with formatting them, other  
> than
> to modify the model so that more information is had about where they  
> go,
> so they don't jump around between tokens when you format. And that  
> when
> you put extra CRs between them, you meant for them to stay there.
>
> That said, the configurable formatter is kind of a pain because it has
> so many options in it, and they're presented in a "set of screws"
> presentation, where you have to know what to set and how to get the
> desired result you want.
>
> So I'd like to gather feedback on what the hot items are for people,  
> and
> if some of these options couldn't be coalesced to simpler options.
>
> 1) Periods. Are there people out there that want to put periods at the
> end of the every block but NOT the end of methods? Rather than two
> binary settings, it seems one could reduce this option to:
> + "only when necessary"
> + "at the ends of methods"
> + "at the ends of methods AND blocks".
>
> 2) Method comments. You've got a knob for newlines after method
> comments. And another knob for the same before method body. One for
> after temporaries. And another for after the method pattern. But are
> there people who set one two 5, and another to 3. It seems everyone
> wants at least one cr at the end, and sometimes a blank line before  
> the
> next element. Could this be reasonably reduced to something like:
> + "Compact (no blank lines between)"
> + "After comments (one blank line at the end of all the comments)"
> + "Always One (one blank like after the comments or pattern if no
> comments)"
> + "Extreme" (put a blank line in between every element)
>
> 3) Strings after/before () and [] and ^. Are there those that put  
> spaces
> for ()'s, but not for blocks? Do some really want to be able to put 3
> spaces? or tabs? Could this be simplified as:
> + "Compact" (no spaces)
> + "Spaces" (put a space between ^ andReturnValue, as well as after/
> before () and []s).
>
> 4) Indent String. Does anyone set this to other than a single tab? And
> if this were an adjustable thing, wouldn't it be better to make the
> width of the tabs in a code view be settable, rather than tune this
> string?
>
> --
> Travis Griggs
> Objologist
> What's next, Intel Processors branded with "Apple Outside" stickers?
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> --------------------------------------------------------
> This message may contain confidential information and is intended  
> for specific recipients unless explicitly noted otherwise. If you  
> have reason to believe you are not an intended recipient of this  
> message, please delete it and notify the sender. This message may  
> not represent the opinion of IntercontinentalExchange, Inc. (ICE),  
> its subsidiaries or affiliates, and does not constitute a contract  
> or guarantee. Unencrypted electronic mail is not secure and the  
> recipient of this message is expected to provide safeguards from  
> viruses and pursue alternate means of communication where privacy or  
> a binding message is desired.
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> I've been playing with handling comments better in the RBParser/
> Formatter. I haven't actually done much with formatting them, other than
> to modify the model so that more information is had about where they go,
> so they don't jump around between tokens when you format. And that when
> you put extra CRs between them, you meant for them to stay there.
>
> That said, the configurable formatter is kind of a pain because it has
> so many options in it, and they're presented in a "set of screws"  
> presentation, where you have to know what to set and how to get the
> desired result you want.
>
> So I'd like to gather feedback on what the hot items are for people, and
> if some of these options couldn't be coalesced to simpler options.
>
> 1) Periods. Are there people out there that want to put periods at the
> end of the every block but NOT the end of methods? Rather than two
> binary settings, it seems one could reduce this option to:
> + "only when necessary"
> + "at the ends of methods"
> + "at the ends of methods AND blocks".
>
> 2) Method comments. You've got a knob for newlines after method
> comments. And another knob for the same before method body. One for
> after temporaries. And another for after the method pattern. But are
> there people who set one two 5, and another to 3. It seems everyone
> wants at least one cr at the end, and sometimes a blank line before the
> next element. Could this be reasonably reduced to something like:
> + "Compact (no blank lines between)"
> + "After comments (one blank line at the end of all the comments)"
> + "Always One (one blank like after the comments or pattern if no
> comments)"
> + "Extreme" (put a blank line in between every element)
>
> 3) Strings after/before () and [] and ^. Are there those that put spaces
> for ()'s, but not for blocks? Do some really want to be able to put 3
> spaces? or tabs? Could this be simplified as:
> + "Compact" (no spaces)
> + "Spaces" (put a space between ^ andReturnValue, as well as after/
> before () and []s).
>
> 4) Indent String. Does anyone set this to other than a single tab? And  
> if this were an adjustable thing, wouldn't it be better to make the  
> width of the tabs in a code view be settable, rather than tune this  
> string?
>
> --
> Travis Griggs
> Objologist
> What's next, Intel Processors branded with "Apple Outside" stickers?
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>  
> --------------------------------------------------------
> This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>
>  

> Travis,
>
> Here are the options I'd look for:
>
> Indent one tab per for each multi-line nested block. The block starting
> bracket is the last token on the statement line that began it. The block
> ending bracket is in visual alignment with the start of the statement
> that began the block. Use periods for all statements except statements
> that return from the method. All cascaded messages (that can't fit on a
> single line) should be intended one level from the receiver. When the
> receiver of cascaded message is the result of a unary message then
> enclose receiver code in (). Don't automatically add # to symbols within
> literal arrays.
>
>  

> I've been playing with handling comments better in the RBParser/
> Formatter. I haven't actually done much with formatting them, other  
> than to modify the model so that more information is had about where  
> they go, so they don't jump around between tokens when you format. And  
> that when you put extra CRs between them, you meant for them to stay  
> there.
>
> That said, the configurable formatter is kind of a pain because it has  
> so many options in it, and they're presented in a "set of screws"  
> presentation, where you have to know what to set and how to get the  
> desired result you want.
>
> So I'd like to gather feedback on what the hot items are for people,  
> and if some of these options couldn't be coalesced to simpler options.
>
> 1) Periods. Are there people out there that want to put periods at the  
> end of the every block but NOT the end of methods? Rather than two  
> binary settings, it seems one could reduce this option to:
> + "only when necessary"
> + "at the ends of methods"
> + "at the ends of methods AND blocks".
>
> 2) Method comments. You've got a knob for newlines after method  
> comments. And another knob for the same before method body. One for  
> after temporaries. And another for after the method pattern. But are  
> there people who set one two 5, and another to 3. It seems everyone  
> wants at least one cr at the end, and sometimes a blank line before  
> the next element. Could this be reasonably reduced to something like:
> + "Compact (no blank lines between)"
> + "After comments (one blank line at the end of all the comments)"
> + "Always One (one blank like after the comments or pattern if no  
> comments)"
> + "Extreme" (put a blank line in between every element)
>
> 3) Strings after/before () and [] and ^. Are there those that put  
> spaces for ()'s, but not for blocks? Do some really want to be able to  
> put 3 spaces? or tabs? Could this be simplified as:
> + "Compact" (no spaces)
> + "Spaces" (put a space between ^ andReturnValue, as well as after/
> before () and []s).
>
> 4) Indent String. Does anyone set this to other than a single tab? And  
> if this were an adjustable thing, wouldn't it be better to make the  
> width of the tabs in a code view be settable, rather than tune this  
> string?
>
> --
> Travis Griggs
> Objologist
> What's next, Intel Processors branded with "Apple Outside" stickers?
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

> Travis, List:
>                    I don't know if this already
> exists, so in case it does sorry for bothering.
> One of the things that annoys me is to see code from
> other developers formatted in a different way that I
> do. So, if I could define a formatter that yields
> acceptable results, it would be nice to have a feature
> to "autofomat" the code when is displayed in the RB. Of
> course I don't mean to recompile the sources, just
> instead of showing the code, to show the formatted
> version.

> On Mar 5, 2008, at 6:14 AM, Andres Fortier wrote:
>
>> Travis, List:
>>                    I don't know if this already
>> exists, so in case it does sorry for bothering.
>> One of the things that annoys me is to see code from
>> other developers formatted in a different way that I
>> do. So, if I could define a formatter that yields
>> acceptable results, it would be nice to have a feature
>> to "autofomat" the code when is displayed in the RB. Of
>> course I don't mean to recompile the sources, just
>> instead of showing the code, to show the formatted
>> version.
>
> The Formatting page in 7.6 has the terse option to enable "Browse Auto
> Formats". Turn that on. I agree with you very much. It's like suddenly I
> wrote all of the code and it all looks the way I want, kind of.
>
> --
> Travis Griggs
> Objologist
> Time and Countertops. They both get used up way too fast.
>
>
>

> dateTime value.</xs:documentation>
> </xs:annotation>
> <xs:union memberTypes="xs:date xs:dateTime"/>
> </xs:simpleType>'
>
> and I'm getting a "Can not parse union type" errors.
> Are unions not supported ? How do you deal with them ?
>
> Thanks in advance.
> martin
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc