Methods should not have too many parameters - configuring / disabling for constructors

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Methods should not have too many parameters - configuring / disabling for constructors

Filippo Munafò

Hi all,

I’d like you to check again the following request:

http://narkive.com/CpTCXkQA

 

We have the same “problem”, and we think the I should at least create to different rules, one for method and one for constructor method.

 

To substantiate the request, let me quote from “Code Complete 2nd Edition, Steve McConnel”:

 

-----------------------

Initialize all member data in all constructors, if possible:

Initializing all data members in all constructors is an inexpensive defensive programming practice.

 

Initialize a class’s member data in its constructor:

Just as a routine’s variables should be initialized within each routine, a class’s data should be initialized within its constructor.

If memory is allocated in the constructor, it should be freed in the destructor.

 

Limit the number of a routine’s parameters to about seven

Seven is a magic number for people’s comprehension. Psychological research has found that people generally

cannot keep track of more than about seven chunks of information at once (Miller

1956). This discovery has been applied to an enormous number of disciplines, and it

seems safe to conjecture that most people can’t keep track of more than about seven

routine parameters at once.

In practice, how much you can limit the number of parameters depends on how your

language handles complex data types. If you program in a modern language that supports

structured data, you can pass a composite data type containing 13 fields and

think of it as one mental “chunk” of data. If you program in a more primitive language,

you might need to pass all 13 fields individually.

-------------------------

 

 

Thanks,

Filippo

Reply | Threaded
Open this post in threaded view
|

Re: Methods should not have too many parameters - configuring / disabling for constructors

Nicolas Peru
Hi, 

For me there is no difference for this rule between methods and constructor. If you end up with 13 parameters in a constructor, then there is probably some refactoring to be done to actually pack some of those parameters in a composite data.

Your quote is actually abunding in this sense as far as I understand.

Cheers, 

Nicolas PERU | SonarSource
Senior Developer
http://sonarsource.com


2015-02-27 12:03 GMT+01:00 Filippo Munafò <[hidden email]>:

Hi all,

I’d like you to check again the following request:

http://narkive.com/CpTCXkQA

 

We have the same “problem”, and we think the I should at least create to different rules, one for method and one for constructor method.

 

To substantiate the request, let me quote from “Code Complete 2nd Edition, Steve McConnel”:

 

-----------------------

Initialize all member data in all constructors, if possible:

Initializing all data members in all constructors is an inexpensive defensive programming practice.

 

Initialize a class’s member data in its constructor:

Just as a routine’s variables should be initialized within each routine, a class’s data should be initialized within its constructor.

If memory is allocated in the constructor, it should be freed in the destructor.

 

Limit the number of a routine’s parameters to about seven

Seven is a magic number for people’s comprehension. Psychological research has found that people generally

cannot keep track of more than about seven chunks of information at once (Miller

1956). This discovery has been applied to an enormous number of disciplines, and it

seems safe to conjecture that most people can’t keep track of more than about seven

routine parameters at once.

In practice, how much you can limit the number of parameters depends on how your

language handles complex data types. If you program in a modern language that supports

structured data, you can pass a composite data type containing 13 fields and

think of it as one mental “chunk” of data. If you program in a more primitive language,

you might need to pass all 13 fields individually.

-------------------------

 

 

Thanks,

Filippo


Reply | Threaded
Open this post in threaded view
|

RE: Methods should not have too many parameters - configuring / disabling for constructors

mattadamson

I agree with Filippo and Nicolas however sometimes it’s not easy or possible to create these composite data structures too or indeed they can’t be combined in a meaningful way.  Constructor really are treated different in this respect so providing users the following options would be useful

 

1)      Two separate rules based on either methods / constructors

2)      Providing control of the magic number 7 for both rules which could be set higher / lower depending on the customer

 

 

From: Nicolas Peru [mailto:[hidden email]]
Sent: 06 March 2015 09:43
To: [hidden email]
Subject: Re: [sonar-user] Methods should not have too many parameters - configuring / disabling for constructors

 

Hi, 

 

For me there is no difference for this rule between methods and constructor. If you end up with 13 parameters in a constructor, then there is probably some refactoring to be done to actually pack some of those parameters in a composite data.

 

Your quote is actually abunding in this sense as far as I understand.

 

Cheers, 


Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

 

 

2015-02-27 12:03 GMT+01:00 Filippo Munafò <[hidden email]>:

Hi all,

I’d like you to check again the following request:

http://narkive.com/CpTCXkQA

 

We have the same “problem”, and we think the I should at least create to different rules, one for method and one for constructor method.

 

To substantiate the request, let me quote from “Code Complete 2nd Edition, Steve McConnel”:

 

-----------------------

Initialize all member data in all constructors, if possible:

Initializing all data members in all constructors is an inexpensive defensive programming practice.

 

Initialize a class’s member data in its constructor:

Just as a routine’s variables should be initialized within each routine, a class’s data should be initialized within its constructor.

If memory is allocated in the constructor, it should be freed in the destructor.

 

Limit the number of a routine’s parameters to about seven

Seven is a magic number for people’s comprehension. Psychological research has found that people generally

cannot keep track of more than about seven chunks of information at once (Miller

1956). This discovery has been applied to an enormous number of disciplines, and it

seems safe to conjecture that most people can’t keep track of more than about seven

routine parameters at once.

In practice, how much you can limit the number of parameters depends on how your

language handles complex data types. If you program in a modern language that supports

structured data, you can pass a composite data type containing 13 fields and

think of it as one mental “chunk” of data. If you program in a more primitive language,

you might need to pass all 13 fields individually.

-------------------------

 

 

Thanks,

Filippo

 

Reply | Threaded
Open this post in threaded view
|

Re: Methods should not have too many parameters - configuring / disabling for constructors

Nicolas Peru
Hi, 

I can agree with the fact that you can different level of requirement depending if you are looking at constructor or method, as consequence : http://jira.codehaus.org/browse/SONARJAVA-926

Cheers, 

Nicolas PERU | SonarSource
Senior Developer
http://sonarsource.com


2015-03-06 13:23 GMT+01:00 Adamson, Matthew <[hidden email]>:

I agree with Filippo and Nicolas however sometimes it’s not easy or possible to create these composite data structures too or indeed they can’t be combined in a meaningful way.  Constructor really are treated different in this respect so providing users the following options would be useful

 

1)      Two separate rules based on either methods / constructors

2)      Providing control of the magic number 7 for both rules which could be set higher / lower depending on the customer

 

 

From: Nicolas Peru [mailto:[hidden email]]
Sent: 06 March 2015 09:43
To: [hidden email]
Subject: Re: [sonar-user] Methods should not have too many parameters - configuring / disabling for constructors

 

Hi, 

 

For me there is no difference for this rule between methods and constructor. If you end up with 13 parameters in a constructor, then there is probably some refactoring to be done to actually pack some of those parameters in a composite data.

 

Your quote is actually abunding in this sense as far as I understand.

 

Cheers, 


Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

 

 

2015-02-27 12:03 GMT+01:00 Filippo Munafò <[hidden email]>:

Hi all,

I’d like you to check again the following request:

http://narkive.com/CpTCXkQA

 

We have the same “problem”, and we think the I should at least create to different rules, one for method and one for constructor method.

 

To substantiate the request, let me quote from “Code Complete 2nd Edition, Steve McConnel”:

 

-----------------------

Initialize all member data in all constructors, if possible:

Initializing all data members in all constructors is an inexpensive defensive programming practice.

 

Initialize a class’s member data in its constructor:

Just as a routine’s variables should be initialized within each routine, a class’s data should be initialized within its constructor.

If memory is allocated in the constructor, it should be freed in the destructor.

 

Limit the number of a routine’s parameters to about seven

Seven is a magic number for people’s comprehension. Psychological research has found that people generally

cannot keep track of more than about seven chunks of information at once (Miller

1956). This discovery has been applied to an enormous number of disciplines, and it

seems safe to conjecture that most people can’t keep track of more than about seven

routine parameters at once.

In practice, how much you can limit the number of parameters depends on how your

language handles complex data types. If you program in a modern language that supports

structured data, you can pass a composite data type containing 13 fields and

think of it as one mental “chunk” of data. If you program in a more primitive language,

you might need to pass all 13 fields individually.

-------------------------

 

 

Thanks,

Filippo