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 <sven@stfx.eu> To: A friendly place where any question about pharo is welcome <pharo-users@lists.gforge.inria.fr> 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
On 18 Dec 2012, at 10:05, dimitris chloupis <thekilon@yahoo.co.uk> 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 <sven@stfx.eu> To: A friendly place where any question about pharo is welcome <pharo-users@lists.gforge.inria.fr> 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 <sven@stfx.eu> To: dimitris chloupis <thekilon@yahoo.co.uk>; A friendly place where any question about pharo is welcome <pharo-users@lists.gforge.inria.fr> 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 <thekilon@yahoo.co.uk> 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 <sven@stfx.eu> To: A friendly place where any question about pharo is welcome <pharo-users@lists.gforge.inria.fr> 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
On 18 December 2012 10:42, dimitris chloupis <thekilon@yahoo.co.uk> 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.
this mode would be not very nice for quick prototyping. 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 <siguctua@gmail.com> To: dimitris chloupis <thekilon@yahoo.co.uk>; A friendly place where any question about pharo is welcome <pharo-users@lists.gforge.inria.fr> Sent: Tuesday, 18 December 2012, 15:22 Subject: Re: [Pharo-users] Nautilius Method Source Pane Coloring On 18 December 2012 10:42, dimitris chloupis <thekilon@yahoo.co.uk> 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.
this mode would be not very nice for quick prototyping. 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.
On Tue, Dec 18, 2012 at 10:42 AM, dimitris chloupis <thekilon@yahoo.co.uk>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 <m.magyar3@gmail.com> To: dimitris chloupis <thekilon@yahoo.co.uk>; A friendly place where any question about pharo is welcome <pharo-users@lists.gforge.inria.fr> 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 <thekilon@yahoo.co.uk> 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.
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
participants (5)
-
Attila Magyar -
dimitris chloupis -
Igor Stasenko -
Stéphane Ducasse -
Sven Van Caekenberghe