Find correlated parameters and suggest possible objects

[anapaulagomes]

After finding the top 10 methods with long parameter list smell, we should suggest which objects could be created according to the parameters who appear together. For instance:

Output from Django project with:

method_name [path] [parameters] number_of_parameters

render [tests/repos/django-master/django/shortcuts.py] ['request', 'template_name', 'context', 'content_type', 'status', 'using'] 6
create [tests/repos/django-master/django/contrib/admin/filters.py] ['field', 'request', 'params', 'model', 'model_admin', 'field_path'] 6
kml [tests/repos/django-master/django/contrib/gis/sitemaps/views.py] ['request', 'label', 'model', 'field_name', 'compress', 'using'] 6
run [tests/repos/django-master/django/core/servers/basehttp.py] ['addr', 'port', 'wsgi_handler', 'ipv6', 'threading', 'server_cls'] 6
data [tests/repos/django-master/django/contrib/gis/gdal/raster/band.py] ['data', 'offset', 'size', 'shape', 'as_memoryview'] 5
kmz [tests/repos/django-master/django/contrib/gis/sitemaps/views.py] ['request', 'label', 'model', 'field_name', 'using'] 5
dumps [tests/repos/django-master/django/core/signing.py] ['obj', 'key', 'salt', 'serializer', 'compress'] 5
loads [tests/repos/django-master/django/core/signing.py] ['s', 'key', 'salt', 'serializer', 'max_age'] 5
migrate [tests/repos/django-master/django/db/migrations/executor.py] ['targets', 'plan', 'state', 'fake', 'fake_initial'] 5
connect [tests/repos/django-master/django/db/models/signals.py] ['receiver', 'sender', 'weak', 'dispatch_uid', 'apps'] 5

Goal

Correlated parameters and possible objects:

(request, model)
(field_name, model)
(key, salt, serializer)

[ayharano]

Just trying to understand before digging into code...

• How do you count those parameters? Does it count only required parameters or does it also count default value set parameters?
• Are args and kwargs being counted? If not, should we?
• I didn't understand the steps between the listing and the goal. At least for me, it doesn't sound like an obvious flow. Could you please elaborate what is your line of thinking to generate the goal tuples?

[anapaulagomes]

Answering the questions:

• The idea is ignoring the default parameters and things like self on parameter list; the project is quite in the beginning but the idea is to have an abstract implementation to any language; but current, we have methods to "clean" the method list:

  looong/looong/extractor.py

  Line 41 in d384a03

  def __clean_parameters(self, raw_parameters_list):

• I don't think so. Maybe the extensive use of them could be considered as a primitive obsession... but not part of this smell. :) What do you think?
• I'm not sure if this problem is recurrent in Python but in languages like Java (the language that I was programming at the time I began this little project) methods with long parameter list pointing to a problem with OO principles. One of the approach to solve is creating objects with the parameters that appear more together. Makes sense?

[anapaulagomes]

By the way, I'll write more about it on README. Thanks!

[ayharano]

• I'm not sure if this problem is recurrent in Python but in languages like Java (the language that I was programming at the time I began this little project) methods with long parameter list pointing to a problem with OO principles. One of the approach to solve is creating objects with the parameters that appear more together. Makes sense?

From the README, it wasn't clear that this library should be used as a tool to other languages, not just Python. Having this in mind, I think there are other conditions I should be considering. I still don't know to proceed considering that newly presented context.

I'll just reply about the other bullet points later.

[anapaulagomes]

The idea is making this configurable. But this is an MVP, so we should just think about Python. But I don't see any trouble because in the end the analysis will be made on top of a list of words.