Nautilius Method Source Pane Coloring
Locked
Nautilius Method Source Pane Coloring
 
|
Hi,
The way Nautilus colors method source panes is absolutely great: if reminds you of paying attention to long methods in a gentle way. However, right now the metric is 'number of characters in method source', while it should be more related to complexity. For example, using long names for variables or messages will be counted as negative towards this metric. Worse even, lots of comments, which is good most of the time, also counts as negative. Number of nodes in the AST would be one solution, but maybe a too expensive one. Maybe quickly scanning for tokens while skipping whitespace and comments and then counting the tokens would be doable ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill |
|
|
There is no such thing as too lengthy comments or too many comments as far as me is concerned
Actually I would prefer if all that effort you are asking here would be spent on documenting those libraries in the first place. Trying to figure out Morphic by reading code is definetly not fun. From: Sven Van Caekenberghe <[hidden email]> To: A friendly place where any question about pharo is welcome <[hidden email]> Sent: Tuesday, 18 December 2012, 10:43 Subject: [Pharo-users] Nautilius Method Source Pane Coloring Hi, The way Nautilus colors method source panes is absolutely great: if reminds you of paying attention to long methods in a gentle way. However, right now the metric is 'number of characters in method source', while it should be more related to complexity. For example, using long names for variables or messages will be counted as negative towards this metric. Worse even, lots of comments, which is good most of the time, also counts as negative. Number of nodes in the AST would be one solution, but maybe a too expensive one. Maybe quickly scanning for tokens while skipping whitespace and comments and then counting the tokens would be doable ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill |
Re: Nautilius Method Source Pane Coloring
|
|
On 18 Dec 2012, at 10:05, dimitris chloupis <[hidden email]> wrote: > There is no such thing as too lengthy comments or too many comments as far as me is concerned > Actually I would prefer if all that effort you are asking here would be spent on documenting those libraries in the first place. Trying to figure out Morphic by reading code is definetly not fun. Euh, I am not sure what your remark has to do with what I wrote about a specific feature, although I can understand your frustration with Morphic. All the open source code that I wrote is clean, unit tested and documented. I don't think you can ask anybody to start documenting something like Morphic… > From: Sven Van Caekenberghe <[hidden email]> > To: A friendly place where any question about pharo is welcome <[hidden email]> > Sent: Tuesday, 18 December 2012, 10:43 > Subject: [Pharo-users] Nautilius Method Source Pane Coloring > > Hi, > > The way Nautilus colors method source panes is absolutely great: if reminds you of paying attention to long methods in a gentle way. > > However, right now the metric is 'number of characters in method source', while it should be more related to complexity. > > For example, using long names for variables or messages will be counted as negative towards this metric. Worse even, lots of comments, which is good most of the time, also counts as negative. > > Number of nodes in the AST would be one solution, but maybe a too expensive one. > > Maybe quickly scanning for tokens while skipping whitespace and comments and then counting the tokens would be doable ? > > Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill |
|
|
ah sorry I missed "worse even". I thought you suggesting that writting long comments should be counted as negative. Also I never asked anybody to start documenting Morphic, I only said I would prefer if focus was more on documentation than improving existing features. Also I dont find that red color thing an importan feature anyway. Though I do find writting small readable well commented methods extremely important. If a coder cant figure out what clean code is and why he should do it, I don't think some red color in the side is going to stop him. The problem is that most people start "dirty" with the desire to clean later, of course
they realise that cleaning the code later is actually a lot of work and never do it. I did see that happen a lot when I was doing python for blender addons. Fortunately the situation with pharo is a lot better. I am actually considering forcing clean code , with my project . Because I will be redesigning all those tools of course basing it in the existing great work that there is . And was wondering how much a bad idea that is. For example moving comments outside the method source code using something like meta tags and forcing the method never to exceed 10 lines. Sound like a bad idea to me, but still makes me think if there is potential. Another example would be not to allow accepting a method if is not commented. Could annoy some people , but I
wonder if there is any real benefit in the long run. From: Sven Van Caekenberghe <[hidden email]> To: dimitris chloupis <[hidden email]>; A friendly place where any question about pharo is welcome <[hidden email]> Sent: Tuesday, 18 December 2012, 11:21 Subject: Re: [Pharo-users] Nautilius Method Source Pane Coloring On 18 Dec 2012, at 10:05, dimitris chloupis <[hidden email]> wrote: > There is no such thing as too lengthy comments or too many comments as far as me is concerned > Actually I would prefer if all that effort you are asking here would be spent on documenting those libraries in the first place. Trying to figure out Morphic by reading code is definetly not fun. Euh, I am not sure what your remark has to do with what I wrote about a specific feature, although I can understand your frustration with Morphic. All the open source code that I wrote is clean, unit tested and documented. I don't think you can ask anybody to start documenting something like Morphic… > From: Sven Van Caekenberghe <[hidden email]> > To: A friendly place where any question about pharo is welcome <[hidden email]> > Sent: Tuesday, 18 December 2012, 10:43 > Subject: [Pharo-users] Nautilius Method Source Pane Coloring > > Hi, > > The way Nautilus colors method source panes is absolutely great: if reminds you of paying attention to long methods in a gentle way. > > However, right now the metric is 'number of characters in method source', while it should be more related to complexity. > > For example, using long names for variables or messages will be counted as negative towards this metric. Worse even, lots of comments, which is good most of the time, also counts as negative. > > Number of nodes in the AST would be one solution, but maybe a too expensive one. > > Maybe quickly scanning for tokens while skipping whitespace and comments and then counting the tokens would be doable ? > > Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill |
Re: Nautilius Method Source Pane Coloring
|
|
In reply to this post by Sven Van Caekenberghe-2
Good remark.
We plan to have AST support for code editing and navigation in 3.0 so we could really change the metric and use a complexity metric. Counting the number of if statements Stef > Hi, > > The way Nautilus colors method source panes is absolutely great: if reminds you of paying attention to long methods in a gentle way. > > However, right now the metric is 'number of characters in method source', while it should be more related to complexity. > > For example, using long names for variables or messages will be counted as negative towards this metric. Worse even, lots of comments, which is good most of the time, also counts as negative. > > Number of nodes in the AST would be one solution, but maybe a too expensive one. > > Maybe quickly scanning for tokens while skipping whitespace and comments and then counting the tokens would be doable ? > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > |
Re: Nautilius Method Source Pane Coloring
|
|
In reply to this post by kilon
On 18 December 2012 10:42, dimitris chloupis <[hidden email]> wrote:
> ah sorry I missed "worse even". I thought you suggesting that writting long > comments should be counted as negative. > > Also I never asked anybody to start documenting Morphic, I only said I would > prefer if focus was more on documentation than improving existing features. > > Also I dont find that red color thing an importan feature anyway. Though I > do find writting small readable well commented methods extremely important. > If a coder cant figure out what clean code is and why he should do it, I > don't think some red color in the side is going to stop him. > > The problem is that most people start "dirty" with the desire to clean > later, of course they realise that cleaning the code later is actually a lot > of work and never do it. > I did see that happen a lot when I was doing python for blender addons. > Fortunately the situation with pharo is a lot better. > > I am actually considering forcing clean code , with my project . Because I > will be redesigning all those tools of course basing it in the existing > great > work that there is . And was wondering how much a bad idea that is. For > example moving comments outside the method source code using something like > meta tags and forcing the method never to exceed 10 lines. Sound like a bad > idea to me, but still makes me think if there is potential. > > Another example would be not to allow accepting a method if is not > commented. Could annoy some people , but I wonder if there is any real > benefit in the long run. > About the topic: yes, counting the number of AST elements would be better metric for determining whether code "stinks" or not :) -- Best regards, Igor Stasenko. |
|
|
good point . I have to agree. From: Igor Stasenko <[hidden email]> To: dimitris chloupis <[hidden email]>; A friendly place where any question about pharo is welcome <[hidden email]> Sent: Tuesday, 18 December 2012, 15:22 Subject: Re: [Pharo-users] Nautilius Method Source Pane Coloring On 18 December 2012 10:42, dimitris chloupis <[hidden email]> wrote: > ah sorry I missed "worse even". I thought you suggesting that writting long > comments should be counted as negative. > > Also I never asked anybody to start documenting Morphic, I only said I would > prefer if focus was more on documentation than improving existing features. > > Also I dont find that red color thing an importan feature anyway. Though I > do find writting small readable well commented methods extremely important. > If a coder cant figure out what clean code is and why he should do it, I > don't think some red color in the side is going to stop him. > > The problem is that most people start "dirty" with the desire to clean > later, of course they realise that cleaning the code later is actually a lot > of work and never do it. > I did see that happen a lot when I was doing python for blender addons. > Fortunately the situation with pharo is a lot better. > > I am actually considering forcing clean code , with my project . Because I > will be redesigning all those tools of course basing it in the existing > great > work that there is . And was wondering how much a bad idea that is. For > example moving comments outside the method source code using something like > meta tags and forcing the method never to exceed 10 lines. Sound like a bad > idea to me, but still makes me think if there is potential. > > Another example would be not to allow accepting a method if is not > commented. Could annoy some people , but I wonder if there is any real > benefit in the long run. > About the topic: yes, counting the number of AST elements would be better metric for determining whether code "stinks" or not :) -- Best regards, Igor Stasenko. |
Re: Nautilius Method Source Pane Coloring
|
|
In reply to this post by kilon
On Tue, Dec 18, 2012 at 10:42 AM, dimitris chloupis <[hidden email]> wrote:
Another example would be not to allow accepting a method if is not commented. Could annoy some people , but I wonder if there is any real benefit in the long ru I think, using comments inside methods and documenting libraries and projects are fairly different topics. I found people often using lots of comments as an excuse for writing unreadable code. But documenting the usage of a library is unarguably important.
|
|
|
you mean by "unreadable code" , bad choice of naming methods and variables or something more than that , or something else ? From: Attila Magyar <[hidden email]> To: dimitris chloupis <[hidden email]>; A friendly place where any question about pharo is welcome <[hidden email]> Sent: Tuesday, 18 December 2012, 15:46 Subject: Re: [Pharo-users] Nautilius Method Source Pane Coloring On Tue, Dec 18, 2012 at 10:42 AM, dimitris chloupis <[hidden email]> wrote: Another example would be not to allow accepting a method if is not commented. Could annoy some people , but I wonder if there is any real benefit in the long ru I think, using comments inside methods and documenting libraries and projects are fairly different topics. I found people often using lots of comments as an excuse for writing unreadable code. But documenting the usage of a library is unarguably important.
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |