[vwnc] Code Formatting
Locked
12
12
 
|
As a sidenote, the "AsYouLikeIt" parcel in the default distribution of 7.5 (and 7.4.1 as well, I think) does exactly what you describe. It's quite nice and I'm glad to hear that this functionality is making its way into the 7.6 default load.
On the general topic of customizable formatter configuration, I actually did write up a code snippet that adds a "Code Formatting" page to the system options. As I wrote it, it collects all of the subclasses of RBFormatter as potential formatting styles and lets you pick one from a drop-down list. I then subclassed RBFormatter and override a few (okay, most) of the methods to implement our project's "standard" code style. It still takes some tweaking from time to time, but it seems to work pretty well. - Ash On Wed, Mar 5, 2008 at 9:14 AM, Andres Fortier <[hidden email]> wrote: Travis, List: _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Bruce Badger
On 06/03/2008, at 8:59 AM, Bruce Badger wrote: > Consider yourself flamed for the completely unnecessary and unfounded > swipe at free and open source software. The problem of too many configuration options in O/S software is not *unfounded*. You may disagree that it's a problem, but unfounded has a specific meaning. If you think it's *unnecessary* to criticize O/S software for what I see as a real and widespread problem, then I guess you are treating O/ S as many treat religion - beyond criticism - but in any case I don't see why any belief system should be out of bounds. I think that my criticism, which is about usability, is an absolutely necessary criticism of O/S software if it is to improve as a tool, rather than an end-in-itself. It is the primary axis (along with documentation) on which O/S software flounders. O/S software is, in general, fantastic, except when it comes to the UI and documentation. Good UIs, and good documentation, require skills and a mindset quite different than the coding chops that O/S attracts. I would further contend that for those tasks which are either not appealing to most developers, or require usability engineering, the process of being commercial i.e. trying to sell software, is a critical motivation. Trying to convince someone to pay for something focusses attention on satisfying the customers needs and desires, both real and perceived. And competition, whether commercial or otherwise, provides an evolutionary selection mechanism. I see this as a key factor in e.g. the quality of distributed version control tools. That's not to say that there aren't exceptions to this - there are a number of O/S GUI tools on OSX that are both attractive and usable. But I think this supports my point - it's the OSX development tools, and a higher level of abstraction that effectively removes options by providing a path of least resistance, that leads to a better product. But on the meta level, which is where I take exception: are you suggesting that expressing an opinion is verboten? I think you should distinguish between disagreeing with what I say, and claiming as you do above that my *having* an opinion or expressing it is in some way invalid. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
On 06/03/2008, Antony Blakey <[hidden email]> wrote:
> > On 06/03/2008, at 8:59 AM, Bruce Badger wrote: > > > Consider yourself flamed for the completely unnecessary and unfounded > > swipe at free and open source software. > > > The problem of too many configuration options in O/S software is not > *unfounded*. You may disagree that it's a problem, but unfounded has a > specific meaning. Quite right. Gratuitous is the word I should have used. So, gratuitous, off topic, unnecessary and unhelpful. > But on the meta level, which is where I take exception: are you > suggesting that expressing an opinion is verboten? I think you should > distinguish between disagreeing with what I say, and claiming as you > do above that my *having* an opinion or expressing it is in some way > invalid. I disagree with you but would defend your right to make your point, which as you pointed out yourself was flame-worthy. So, you invite flames and then complain? Gosh. Enough, perhaps? BTW, do you have any comments on the point I made on-topic perchance? All the best, Bruce -- Make the most of your skills - with OpenSkills http://www.openskills.org/ _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
On 06/03/2008, at 4:20 PM, Bruce Badger wrote: > I disagree with you but would defend your right to make your point, > which as you pointed out yourself was flame-worthy. So, you invite > flames and then complain? I didn't invite flames, merely acknowledge the risk thereof. Nor did I imply, by that declaration, that I wouldn't defend my opinion. The point wasn't gratuitous, off-topic or unnecessary: my point is that overly configurable software is a bad idea when it comes to UIs, and that human factors engineering can be done a lot more objectively i.e. it's not just a matter of taste and therefore not best served by large numbers options and parameters. I was placing the issue of code formatting freedom in the larger context of that concept. IMO an obvious data point is most O/S UI software. Once again, you may disagree with my assertion, but it was relevant to the point. And I cannot think of a better example of the perils of deferring choice to the user. > Enough, perhaps? Yes. > BTW, do you have any comments on the point I made on-topic perchance? I hoped my original post on this issue was clear - the code formatter should embody the best research into the relationship between the visual characteristics of the source e.g. layout/colour/font characteristics, and improved understanding of the code. For example, one rule that needs no research is that semantic hierarchy should be reflected in the visual hierarchy. The degree to which that isomorphism should be strictly maintained is an open question. Another known factor is the relationship of line-length to reading ease, especially during scanning. What are the important markers when scanning Smalltalk code and how should they be represented to easy scanning e.g. bolding of punctuation? Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The intuitive mind is a sacred gift and the rational mind is a faithful servant. We have created a society that honours the servant and has forgotten the gift. -- Albert Einstein _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Antony Blakey-2
Antony Blakey wrote:
> But I think this supports my point - it's the OSX development tools, > and a higher level of abstraction that effectively removes options by > providing a path of least resistance, that leads to a better product. > Apple employs hordes of human interface designers to accomplish this level of abstraction. The art of reducing the set of options while at the same time not limiting the overall functionality of the tool, is extremely demanding. I am experiencing these difficulties with my own products currently and, despite I have some skills in this field, am having a hard time to get this job done in a reasonable time frame. Actually, this is a full time occupation for someone hired for this task alone (if I only could afford one). Well done UI design in the above mentioned sense is not just "nice to have". It's a major selling point. This especially holds true for development tools. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Ash-15
Hi Ash, I didn't know about it, thanks for letting me
know. Now I have to find a formatter that does things the way I like :) Thanks again, Andrés Ash Wilson escribió: > As a sidenote, the "AsYouLikeIt" parcel in the default distribution of 7.5(and > 7.4.1 as well, I think) does exactly what you describe. It's quite nice and > I'm glad to hear that this functionality is making its way into the > 7.6default load. > > On the general topic of customizable formatter configuration, I actually did > write up a code snippet that adds a "Code Formatting" page to the system > options. As I wrote it, it collects all of the subclasses of RBFormatter as > potential formatting styles and lets you pick one from a drop-down list. I > then subclassed RBFormatter and override a few (okay, most) of the methods > to implement our project's "standard" code style. It still takes some > tweaking from time to time, but it seems to work pretty well. > > - Ash > > On Wed, Mar 5, 2008 at 9:14 AM, Andres Fortier < > [hidden email]> 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. >> >> HTH, >> Andrés >> >> Travis Griggs escribió: >>> 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 >>> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Travis Griggs-3
I find this statement very naive:
> human factors engineering can be done a lot more objectively If there's anything that's inherently NOT objective, it's human perception and cognition. What works for one person, can be painful for the next. If there's anything we've learned in decades of HCI research, it's that the best thing we can hope for is to isolate the orthogonal axes of usability, and provide options on those axes. Even the notion of "overly" configurable is subjective. ----- Original Message ---- From: Antony Blakey <[hidden email]> To: Bruce Badger <[hidden email]> Cc: "VWNC," <[hidden email]>; VWDEV List <[hidden email]> Sent: Wednesday, March 5, 2008 10:27:37 PM Subject: Re: [vwnc] Code Formatting On 06/03/2008, at 4:20 PM, Bruce Badger wrote: > I disagree with you but would defend your right to make your point, > which as you pointed out yourself was flame-worthy. So, you invite > flames and then complain? I didn't invite flames, merely acknowledge the risk thereof. Nor did I imply, by that declaration, that I wouldn't defend my opinion. The point wasn't gratuitous, off-topic or unnecessary: my point is that overly configurable software is a bad idea when it comes to UIs, and that human factors engineering can be done a lot more objectively i.e. it's not just a matter of taste and therefore not best served by large numbers options and parameters. I was placing the issue of code formatting freedom in the larger context of that concept. IMO an obvious data point is most O/S UI software. Once again, you may disagree with my assertion, but it was relevant to the point. And I cannot think of a better example of the perils of deferring choice to the user. > Enough, perhaps? Yes. > BTW, do you have any comments on the point I made on-topic perchance? I hoped my original post on this issue was clear - the code formatter should embody the best research into the relationship between the visual characteristics of the source e.g. layout/colour/font characteristics, and improved understanding of the code. For example, one rule that needs no research is that semantic hierarchy should be reflected in the visual hierarchy. The degree to which that isomorphism should be strictly maintained is an open question. Another known factor is the relationship of line-length to reading ease, especially during scanning. What are the important markers when scanning Smalltalk code and how should they be represented to easy scanning e.g. bolding of punctuation? Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The intuitive mind is a sacred gift and the rational mind is a faithful servant. We have created a society that honours the servant and has forgotten the gift. -- Albert Einstein _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
On 07/03/2008, at 1:49 PM, Jim Haungs wrote: > I find this statement very naive: > >> human factors engineering can be done a lot more objectively > > If there's anything that's inherently NOT objective, it's human > perception and cognition. What works for one person, can be painful > for the next. Fitts' law. Line length. 7 +/- 2. Visual/Semantic structural isomorphism. The poor performance of adaptive menus due to position memory. Hick's law. All the work of Don Norman / Jakob Nielsen (admittedly empirical), and others. Much objective data that is valid input into the design of interfaces. Even Tufte is relevant when it comes to system monitoring and reporting, particularly of quantitative data. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The truth does not change according to our ability to stomach it. -- Flannery O'Connor _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |