This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Product Version = NetBeans IDE Dev (Build 201303192300) Operating System = Linux version 3.5.0-26-generic running on amd64 Java; VM; Vendor = 1.7.0_17 Runtime = Java HotSpot(TM) 64-Bit Server VM 23.7-b01 Getting 'Method Length is N Lines (10 allowed)' warning for any php file with methods. 'Class Length is N Lines (100 allowed)' for classes. Also getting warning: 'Too Many Nested Blocks in Function Declaration' for "if {...}" constructions.
Created attachment 132876 [details] IDE log
Sorry, but without provided test file, where the problem occurs, I can't check it. It seems to me that those warning are not false...that you really have big methods and classes. Attach a file, where it can be reproduced, until that, incomplete.
Created attachment 132884 [details] Example file Added example file, wich causes described warnings in a dev, but not in 7.3 IDE version (havn't checked in previous releases)
Sorry, but that hints are valid. You have really big methods :( And it doesn't appear in 7.3, because these are new Hints in the dev. You can simply disable them in Tools->Options->Editor->Hints->PHP to don't disturb you.
Ok, thanks, I've found these new settings and now can adjust them. But why so strict limitations made by default? 10 lines per method? 100 per class? Editor counts not just lines with code but also lines with coments. And I'm pretty sure it's a bad decision. You will get a lot of false reports if 7.3.1 will be released with such confusing default behaviour. Maybe the limit numbers should be like 50/200 and editor should ignore comment lines?
Definitely not. Strict is ok, everyone can modify that, but if the defaults will be too high then whole hint has no sense. Now it forces you to write small classes with small methods and no GOD classes. And if you really want it, then just modify or disable that hint. Sorry. FindBugs (static analysis for Java files) handles Comments in the same way. So I know about that behavior, but sorry, in your files there is almost more comments then code. I don't think that it's a good practice ;) We can talk about handling comments, but it wouldn't be a defect, but an enhancement. Current behavior is intended.
This is an utterly ridiculous hint. Everyone's business needs are different, for example it often takes a long number of lines to set up boilerplate code related to the framework. You're in no place to judge if a method should be 10 lines or 30 lines, making too many small methods is just as bad as having too few very long methods. You should not be judging how many lines a method should have, or trying to teach people programming. Please focus on some valid issues like improving javascript support instead of useless things like these hints.
I don't agree with you. You should refactor. Nevertheless there is a simple way how to solve this issue. Just disable that hint in Options->Editor->Hints->PHP->Too many lines. That't the way and that's why hints are configurable. To disable those you are not interested in. A lot of people have appreciated this hint. So sorry.
Well, before I say anything, let me say that it's very gracious of you guys to accept feedback on a free product in the first place and, furthermore, I think the NetBeans IDE is one of the best IDEs available (free or paid) for working with PHP. My comments on this bug are tendered only in order to improve the IDE. Forgive me, therefore, when I say that you have got to be kidding here, Ondrej. This too-many-lines "hint" is absurd. Yes, of course, you can disable PHP hints related to this "too many lines" matter (and I would imagine anyone with sense WILL disable it), but why include this "feature" in the first place? You might be able to make an argument that comments should be included in the line count, but it would be a very weak argument. PHP is not a compiled language so comments are not excluded in its "final" code as they would be excluded from compiled code, but the rendered HTML page can be considered equivalent to compiled code and PHP comments are removed from HTML output by the PHP interpreter. But, I don't know if comments slow down the interpreter. I can't imagine they would to any consequential degree. But not only does your line-counting hinting logic include comments, WHITE SPACE LINES ARE ALSO COUNTED! No PHP interpreter takes white space lines into account at all, so why would you count them here? That simply makes no sense. Readability is almost always improved by white space in code. You may think this is a valid hint, Ondrej, but at the very least it should be disabled by default and if a developer finds that he tends to write overly long functions and feels he needs his IDE to tell him so (although why he wouldn't be able to count the lines himself is hard to fathom), maybe he can consider enabling this bizarre hint.
This really makes no sense to give a warning when class exceed 100 lines. Do you even tried to write any application with that limitation? Will writing 3-4 classes for one functionality will improve anything? I don't think so. More to say it will complicate code (split), make it harder to read and is pretty ridiculous when creating large framework. Do you image splitting classes of CMS frameworks? For example Joomla, Drupal, Wordpress? Not only it will not help but can slow down application giving more unnecessary disc access.
It's a hint. If you don't want to use it, just disable it or adjust the number of lines. Tools -> Options -> Editor -> Hints -> PHP.
Its a ridiculous hint. At the very least it should be disabled by default.
Thank you Ondrej Brejla for improving an already great IDE. With so many negative comments on here I thought I would add a positive one. :)
Assuming further comment is welcome on this issue, I'd make the following observations: 1. 10 lines (including comments and blanks) for methods seems low. To have put something like this in the editor, presumably it's been based on researched and documented evidence of good coding practice, or at least broad consensus amongst experts. Is it possible to examine this evidence and / or discussion? 2. The word "allowed" is *very* pejorative. If this is a hint, perhaps "suggested" or similar would be more appropriate. Quite apart from talking down to your users, those new to PHP could mistakenly believe that their code actually won't work if they exceed this. 3. Not all users will appreciate that hints like this can be disabled. Explaining here how to do so will not reach the broader user base. Could it be that the apparent need to repeatedly state here that it can be turned off is evidence that a sizeable percentage of people don't want it (or don't want it set this low)?
I'd like to add a couple of my own observations to the previous comment. 1. Ondrej Brejla said above "You can simply disable them in Tools->Options->Editor->Hints->PHP". So sorry, but it is simply not simple. It is five levels down in settings. And not in the obvious "PHP" section, but in Editor>Hints>PHP. I had to google it find out how to do it. It would be simple if I could click on the warning itself and disable it. 2. Have you tried opening Symphony 2 source files with this warnings enabled? Or Yii Framework? Don't these warnings loose any sense when you see them on every class and on every third method? 3. You may say that many people have appreciated this feature, but that is really not an argument. How many people? 5? 10? A hundred? How big your sample group was? What were thay developing? I definitely see many people not appreciating this feature here. :)
Encouraging good practice is not a bad idea. This actually could translate to bad practice - illegible code. I've taken a method of 17 lines and made it 1 line. No hint... Despite the intent this one should default to disabled.
I with my little experience from working in Apple and Qualcomm want to add that I have hardly seen classes (that actually does something) less that 100 lines. The getters and setters may take more than that if you have to specify them. Trying to teach us all programming by default is probably not the best idea. People who found this warning bothersome are usually those who likes to make sure that their code not only are error free, but also follows best practice to be warning free. If they are suggesting that this is not a great feature and at least should be disabled by default, there is something to think about for the netbeans team.
I must agree, this warning is very misleading... I had two very confusing ones: -first was on a __construct() method on a php file, where it said "Method Length is 12 Lines(10 Allowed)" -second was "Method Length is 198 Lines(100 Allowed)" And it never happened on netbeans 7.3 ... misleading, confusing and I really don't understand its purpose. It's meant to encourage us to make constructors with zero lines? :)) That would be pretty awkward... Thank you. Please explain its meaning.
This warning is absurd. 13 lines 10 allowed only. public function CreatePdf() { foreach($this->Pages as $page) { /* @var $page Element */ //calculate sizes $page->Measure(); //arrange elements $page->Arrange(); //render $page->Render($this->pdfWriter); } }
Disable that hint and stop spamming, it's useless. Numbers were increased in dev version. Thanks.
I also think this warning are stupid, even the PHP.NET website best practice recommendations rise some NetBeans 7.4 warnings.....
This hint is really nice. You just have to increased number of lines in your config and stop to complained ! In symfony2 for example, every action should be less than 20 lines, so for me it's a nice feature of be alerted if my function is too longer.
Today I upgraded my Netbeans installation from 7.3 to 7.4 . This hint is really annoying. And when I came to this bug report page I was really surprised to see that this so-called functionality exists since last spring, and that it migrated from beta to stable release. This hint isn't not only useless. It can be harmful. Imagine the amount of new young programmers, who will try to avoid comments, spacings, just because their code doesn't fit in those 10 lines. But expecially I was disappointed by Ondrej Brejla answers. People are not "spamming" here. If you'll read all the comments, you'll see that users gave good arguments why they don't like it. Ondrej, you also told us, that our "spam" is useless. Probably this functionality is useless? Or probably the author of this functionality is useless? Didn't you think about that? With such attitude, alot of users will go to another IDE.
shadypierre: Thanks. xa0c: "Or probably the author of this functionality is useless?" Yep, it seems to be the cause...probably. I wrote you what to do if you don't like it. Just do it. I also wrote that I changed the default behavior in the dev build. Just use it. Can't do more...(probably because I'm useless ;) Sorry, I'll not follow this flame anymore. All thoughts has been written and advices were given. Also improvements were done.
You can do more, which is to disable it by default. Right now you've just increased the number of lines.
Yes, and that's the state, where it will be for few months. We have almost half a year to test it. If it will be disabled, no-one will test it. It's simple.
This hint - as any other hint - can be easily configured or even disabled. So the current state is OK IMHO.
How about not using useless comments and unnecessary whitespaces? If calculate size expresses your intent in a better way than Measure, then just rename the method Measure to CalculateSize(). If you absolutely need to know that you are arranging elements, then use the name ArrangeElements(). Otherwise just delete the redundant comments. And you can create a CreatePdf inside the page which will do all the necessary steps to create the pdf. E.g.: public function CreatePdf() { foreach($this->Pages as $page) { $page->CreatePdf($this->pdfWriter); } } This is 5 lines long. (In reply to bmewburn from comment #19) > This warning is absurd. 13 lines 10 allowed only. > > public function CreatePdf() { > > foreach($this->Pages as $page) > { > /* @var $page Element */ > > //calculate sizes > $page->Measure(); > > //arrange elements > $page->Arrange(); > > //render > $page->Render($this->pdfWriter); > } > }
^ The above comment shows why this hint is not only useless, its actually harmful. Because its encouraging the removal of comments and whitespace. Unless this is modified to not count whitespace and comments, this hint is harmful and should be removed.
Definitely not harmful and useless. Quaentha made a cleaner code from ugly one. To not count WSs and comments, it's a valid enhancement. Then file a new issue, thanks.
(In reply to Ondrej Brejla from comment #30) > Definitely not harmful and useless. Quaentha made a cleaner code from ugly > one. > > To not count WSs and comments, it's a valid enhancement. Then file a new > issue, thanks. Its in no way cleaner. The whitespace made the code a lot more readable. And if you actually think that removing whitespace and comments will make code more readable, you are being ridiculous.
It's definitely cleaner :)) But, sorry...will not spend any other sec to argue with you. For all other rational users, I filed a new issue #237620 to don't count empty lines and comments by Too many lines hint, since it's a valid requirement. Thanks for catching that.
Ondrej, thank you for your work on a great, free product. All the whining, ingrateful jackasses who can't bring themselves to just disable the hint are embarrassing themselves.
(In reply to digitman222 from comment #31) > if you actually think that removing whitespace and comments will make code > more readable, you are being ridiculous. Then I'm ridiculous. I think empty lines are either unnecessary noises, or a sign that smaller method should be factored out.
(In reply to Quaentha from comment #34) > Then I'm ridiculous. I think empty lines are either unnecessary noises, or a > sign that smaller method should be factored out. Indeed you are, because any good programmer uses whitespace and comments to make their code more readable. Perhaps you should consider just coding in machine language so you can avoid all the noise, and only have the most crucial things. I don't see why one developer (Ondrej) should get to monopolize this issue. Given the overwhelming user feedback against this feature, I think this should stay open and another developer from the Netbeans team should respond to this. After all, Netbeans is an open source project.
(In reply to Quaentha from comment #28) > How about not using useless comments and unnecessary whitespaces? If > calculate size expresses your intent in a better way than Measure, then just > rename the method Measure to CalculateSize(). If you absolutely need to know > that you are arranging elements, then use the name ArrangeElements(). > Otherwise just delete the redundant comments. > And you can create a CreatePdf inside the page which will do all the > necessary steps to create the pdf. E.g.: It was a quick copy and paste of a function I was working on (the comments mainly left over from pseudocode of the steps I needed to follow). It was meant to illustrate that a relatively concise function triggers this most absurd warning. The comment content is irrelevant the point is that having code + comments + whitespace >= 10 lines does not mean that your function is in desperate need of refactoring.
(In reply to digitman222 from comment #35) > (In reply to Quaentha from comment #34) > > Then I'm ridiculous. I think empty lines are either unnecessary noises, or a > > sign that smaller method should be factored out. > > Indeed you are, because any good programmer uses whitespace and comments to > make their code more readable. Sorry but this is so amateur, I did this when I was coding in highschool :).
@digitman: 237620(In reply to bmewburn from comment #36) > The comment content is irrelevant the point is that having > code + comments + whitespace >= 10 lines does not mean that your function is > in desperate need of refactoring. Comments and white lines are no more counted, see Bug 237620. (In reply to Quaentha from comment #37) > > Indeed you are, because any good programmer uses whitespace and comments to > > make their code more readable. > > Sorry but this is so amateur, I did this when I was coding in highschool :). Totally agree with you Quaentha, it is amateur to say that :)
All has been said. Enhancement issue #237620 was implemented (it satisfies some complaining users) so closing as fixed, since "now" it works definitely as expected (numbers were increased and whitespaces and comments are not counted). 2 another NB developers responded (tmysik, mmolda - thanks), but digitman is still screaming :) And be careful by using word "overwhelming" :) It seems really ridiculous in the context of all comments, both positive/negativ ;)
Numbers are increased. Comments and empty lines are not counted. Marking as verified. Thanks. Product Version: NetBeans IDE Dev (Build 201310250001) Java: 1.7.0_45; Java HotSpot(TM) Client VM 24.45-b08 Runtime: Java(TM) SE Runtime Environment 1.7.0_45-b18 System: Windows 7 version 6.1 running on x86; Cp1250; en_US (nb)
(In reply to Quaentha from comment #37) > (In reply to digitman222 from comment #35) > > (In reply to Quaentha from comment #34) > > > Then I'm ridiculous. I think empty lines are either unnecessary noises, or a > > > sign that smaller method should be factored out. > > > > Indeed you are, because any good programmer uses whitespace and comments to > > make their code more readable. > > Sorry but this is so amateur, I did this when I was coding in highschool :). Sorry, but it seems, that you are still on highschool level. Teaching others how to write code isn't a good thing. And it seems to be pointless to convince you, that this issue is harmful.
I just encountered this "feature" in NetBeans 7.4. I agree that it's harmful. First, it's not a hint as claimed. It's a warning. The warning is misleading. Second, if the goal is to encourage simpler methods, the hint should be about cyclomatic complexity, not line count.
Just want to go on record that I, too, just encountered this "feature" and must say that this discussion is quite interesting. But an IDE should not force me to use coding standards that are not universal (i.e. that don't throw at at least a strict standards error). I don't know how you could possibly write any kind of complex application while keeping all methods to 10 lines. That said, I don't disagree that it might be a good _optional_ idea to enable this warning, but I echo those who feel that it should be _disabled_ by default, that the way it currently functions implies that your code will not run correctly if you write methods longer than 10 lines, which will most certainly confuse new programmers. And Quaentha, are you saying that commenting your code is amateur? Please remind me never to work on a project that you previously were working on.
(In reply to jdavidbakr from comment #43) > Just want to go on record that I, too, just encountered this "feature" and > must say that this discussion is quite interesting. But an IDE should not > force me to use coding standards that are not universal (i.e. that don't > throw at at least a strict standards error). I don't know how you could > possibly write any kind of complex application while keeping all methods to > 10 lines. That said, I don't disagree that it might be a good _optional_ > idea to enable this warning, but I echo those who feel that it should be > _disabled_ by default, that the way it currently functions implies that your > code will not run correctly if you write methods longer than 10 lines, which > will most certainly confuse new programmers. > > And Quaentha, are you saying that commenting your code is amateur? Please > remind me never to work on a project that you previously were working on. I think Quaentha meant that commenting is bad smell (see http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672). When you comment some code it means that your variable names, method names are not descriptive enough (where are of course exceptions: implementations of different complex algorithms like encrypting for example). Also our comments usually are a technical debt. We always need to keep those up to date with our code, because if you don't do it one time than suddenly comments become irrelevant. I prefer unit tests than excessive commenting because those at least give you a greater understanding of the code and an up-to-immediate feedback. About the small methods: I'm not sure 10 is the right number, but having a small number of lines of code in a method is good. Because it means you are constantly dealing with code refactoring to make your code cleaner and more understandable, and you suddenly can reuse your methods, unit test them or abstract those away into a helper, and so on. If the methods are big (let's say 50 lines) do you think you could easily reuse these methods? I doubt it. You see it is starting from smaller methods and than improving the way you code because of you are constantly thinking on how to make your code smaller and more concise. Of course in the real world there are deadlines and legacy systems and all the other factors, but hey it is just a hint!
(In reply to Monomachus from comment #44) > (In reply to jdavidbakr from comment #43) > > Just want to go on record that I, too, just encountered this "feature" and > > must say that this discussion is quite interesting. But an IDE should not > > force me to use coding standards that are not universal (i.e. that don't > > throw at at least a strict standards error). I don't know how you could > > possibly write any kind of complex application while keeping all methods to > > 10 lines. That said, I don't disagree that it might be a good _optional_ > > idea to enable this warning, but I echo those who feel that it should be > > _disabled_ by default, that the way it currently functions implies that your > > code will not run correctly if you write methods longer than 10 lines, which > > will most certainly confuse new programmers. > > > > And Quaentha, are you saying that commenting your code is amateur? Please > > remind me never to work on a project that you previously were working on. > > I think Quaentha meant that commenting is bad smell (see > http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/ > 0201485672). When you comment some code it means that your variable names, > method names are not descriptive enough (where are of course exceptions: > implementations of different complex algorithms like encrypting for > example). Also our comments usually are a technical debt. We always need to > keep those up to date with our code, because if you don't do it one time > than suddenly comments become irrelevant. I prefer unit tests than excessive > commenting because those at least give you a greater understanding of the > code and an up-to-immediate feedback. > > About the small methods: I'm not sure 10 is the right number, but having a > small number of lines of code in a method is good. Because it means you are > constantly dealing with code refactoring to make your code cleaner and more > understandable, and you suddenly can reuse your methods, unit test them or > abstract those away into a helper, and so on. If the methods are big (let's > say 50 lines) do you think you could easily reuse these methods? I doubt it. > You see it is starting from smaller methods and than improving the way you > code because of you are constantly thinking on how to make your code smaller > and more concise. > > Of course in the real world there are deadlines and legacy systems and all > the other factors, but hey it is just a hint! The use of comments actually depends on the length of code in methods. Of course, if the number of lines will be small, and the code will mostly contain the calls of another methods (with self-describing names), then the commenting isn't really needed. But using call-call-call approach isn't the only way how to write code. Some projects require good optimisation, some require to be single-class. Sometimes it can be an overhead to call some methods inside a loop. There are different tasks for different projects. Thats why forcing a new programmer to think only in one direction will not make him better. IDE shouldn't force the programmer to use only specific style of coding. This is not the task of IDE. Thats why in my opinion this hint is harmful. And unfortunately this hint isn't the only one. Some addict also added a bunch of similar non-sense features (not all, but majority). Check Options>Editor>Hints. As I previously said, its not a task of IDE to force programmer to a specific style.
(In reply to Ondrej Brejla from comment #11) > It's a hint. If you don't want to use it, just disable it or adjust the > number of lines. Tools -> Options -> Editor -> Hints -> PHP. I have just installed Netbeans 7.4 I have a small method of 30 lines and I know it works. Now Netbeans tell me, that only 10 lines are ALLOWED. Since it's a hint, I understand it as "Your method will work, but poorly" First I panicked, all that code I need to rewrite. Then I had to find proof of this statement. I found this place. Thanks all, I thought I was stupid for a moment. Then I thought of all my fellow students. They are not capable of questioning the teacher and defenitely not the program they use. And let's be honest, you made that hint, for the new programmers, not the old ones, who know all about when to split methods. And my question is: Why do you believe, that 10 methods + the ones connecting them, of 10 lines, is better than 1 method of 100 lines? Another thing to consider: When I am done with a file, I remove all comments, whitespaces become 1 space and I remove all line breaks. So my previusly mentioned 30 line method, is now 1 line. Now it runs much better ? Actually, what you are saying is: Methods don't like linebreaks, use max 10, or php gets stress.
*** Bug 238956 has been marked as a duplicate of this bug. ***
10 ALLOWED. I've just upgraded to 7.4 and like most others here have found this quite ludicrous. Hinting that 10 lines are the maximum ALLOWED is not simply unhelpful, it's just plain inaccurate. (yes, Inaccurate means wrong). Please don't anyone take this personally, just remove this 'feature' by default.
Upgrade to patch 1 (improvements and fixes were applied) and don't change meta data of verified issues.
In less than 10 lines: 1. Even if you were to make a recommendation on coding standards on wikipedia, you would need to provide some form of reference. 2. Nowhere, (until now) have I seen it suggested (never mind ALLOWED) that there is any kind of limit, or recommended limit on the line count (with or without comments and whitespace) of PHP classes or methods. 3. The opinions of your high school teachers or peers are nothing more than opinion until some kind of official recommendation has been suggested and accepted. 4. It is not the task of netbeans developers to arbitrarily define new and unaccepted coding standards in any language. 5. Any real-world code WILL contain methods more than 10 lines (I say this as a 42 year old who has not been to school for some time). 6. Good programming practice is something learned by good programming experience, and adhering to accepted recommendations is important. Your IDE should HELP by pointing out accepted coding recommendations. (we all like to see green lights on our files) 7. The number of reporters on this bug who are against suggest that it is a very unpopular 'feature'. 8. Ondrej- 'Sorry, but that hints are valid.' According to who? 9. Ondrej- 'It's a hint. If you don't want to use it, just disable it' Please remove this default behavior, it damages netbeans.
danTheMan: Once again, please do NOT change meta data of fixed and verified issue. As Ondrej says, try to upgrade to Patch 1 (if you did not already), there are some improvements. Also, the numbers will be increased in the next NetBeans version. It is already done in dev version.
I also think this is very misleading for new php programers, I've downloaded the newest IDE 7.4, and it still says ALLOWED. At first I thought that PHP had changed there standard for how long functions/methods can be... Can't you just call it recommend 10 lines... so it doesn't freak people out?
(In reply to Monomachus from comment #44) > I think Quaentha meant that commenting is bad smell (see > http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/ > 0201485672). When you comment some code it means that your variable names, > method names are not descriptive enough (where are of course exceptions: > implementations of different complex algorithms like encrypting for > example). Also our comments usually are a technical debt. We always need to > keep those up to date with our code, because if you don't do it one time > than suddenly comments become irrelevant. I prefer unit tests than excessive > commenting because those at least give you a greater understanding of the > code and an up-to-immediate feedback. I learned 30 years ago (thankfully) that code is not complete unless and until it is commented such that another programmer can look at it and understand the intent of the author. Selecting useful method and variable names is important (and often challenging). But there is no substitute for proper commenting of code, especially when it comes to documenting method calls. Almost every real-world programmer has had to deal with code written by someone who was too smart--or too lazy--and who did not think it was important to state their intentions in comments; and they have suffered and wasted time because if it. To me, commenting my code so that someone else can understand it is a point of professional pride. IT IS PART OF MY JOB to create useful comments and to maintain them when I make changes to the code.
I'm fine with these hints as long as they are labelled properly (as suggestions) by default and we could disable them en masse by their type (hint or suggestion). I initially thought I was getting a PHP compiler warning and spent 10 minutes reading this to find out it's just NetBeans' developer's "best practice" hints, which are arbitrary (and not necessarily best for the situation) and get in the way of real coding. Also the "allowed" part has nothing to do with PHP rules or any restriction or authority. I suggest changing their "Show As" default to "Hint" or "Suggestion" rather than "Warning" and allowing us to disable them with one checkbox.
Looking closer at this, a lot of these are actually useful, such as marking variables that aren't used or the PSR coding standards, but I disabled the Too Many Lines section and some other things are just not very useful to have enabled by default and get in the way. Also, NetBeans has other issues that are more important than these and should have more time spent on them, such as lines following a method call line indenting multiple times as opposed to once following if/while lines, or commented lines not keeping relative indents on auto-formatting.
I changed the options I left checked (since they looked useful) to "Suggestion for current line" since I still wanted to see them but marked differently than a PHP warning, but all notation for them then disappeared in the code, including the yield sign symbols; not even hitting Alt+Enter on the line showed anything. I did notice a light-bulb triangle icon but I'm not sure what caused it and it disappeared. I would prefer to have suggestions marked with their own icon and still show the message on hover and Alt+Enter. It took some time to mark them all as "suggestion" so I wish there was a better way to turn off all "best practice" warnings or change their type.
Hello Ondrej Brejla Now with the release of Netbeans 8, I can see that the default length for methods is 20, but I can imagine a simple situation where this is not useful and it is where you have to implement that beautiful closure methods of PHP 5.3+ known as Lambda function as well, or also with a simple switch statement. /** * Comments should be here and only here * @param int $param * @param int $days * return int */ function outer($param, $days){ $ret = 1; switch($param){ case 1: $p = doSomethingIfParamIs1($param); $ret+= method1($p); break; case 2: $p = doSomethingIfParamIs2($param); $ret+= method2($p); break; case 3: $p = doSomethingIfParamIs3($param); $ret+= method3($p); break; case 4: $p = doSomethingIfParamIs4($param); $ret+= method4($p); break; case 5: $p = doSomethingIfParamIs5($param); $ret+= method5($p); break; default: $p = doSomethingIfParamIsOther($param); $ret+= method6($p); break; } return ($ret * $days) * 0.25; } As you can see, there are 28 lines in this method and I think there is nothing bad with this kind of code, also, it shouldn't be splitted in several more methods because it would be unreadable. So i'm a little curious about this situation, could you please give me a reference where I can read about this "max length" convention?, is it just common sense or something that programmer have known for ever? thanks.
About my last comment, I know I could do this $ret+= methodX(doSomethingIfParamIsX($param)); Just try to imagine a situation where you need a switch with 5 cases, each of them with 3 lines of code (5 - including the case x: and the break; lines) and a last line with a return. that would be 27 lines of code. Also, bear in mind that if I'm here giving some feedback is because I appreciate your effort and I am trying to find answers to my "best practices" quest. Also I have to say that I never write "God methods", I think the longest that I have written is about 35 lines long and I really think that I shouldn't split them anymore. Regards.
Just realize that hints are only suggestions, it doesn't say that "this part of code is absolutely wrong" it just says..."this is somehow strange, so be careful", so you'll look at it, consider it as ok and go on. And it your case...you can of course refactor and use polymorphism instead of crapy switch ;) (but I know what you mean, I got your point ;)
See the option (8.0.1) Tools -> Options -> Editor -> Hints -> PHP...and can be deactivated at all (In reply to Ondrej Brejla from comment #59) > Just realize that hints are only suggestions, it doesn't say that "this part > of code is absolutely wrong" it just says..."this is somehow strange, so be > careful", so you'll look at it, consider it as ok and go on. > > And it your case...you can of course refactor and use polymorphism instead > of crapy switch ;) (but I know what you mean, I got your point ;)
This warning definitely needs to be reworded. I was just starting out with PHP, and upon seeing this warning I was under the impression that the method length limit was imposed by the compiler, not some guy on the internet's opinion. It needs to be made clear that this is a suggestion, not an actual limit as implied by the warning. Please don't just reply to me telling me how to disable the hint, I appreciate its intent, but it is very misleading to people unfamiliar with PHP.
The fact that i searched for a standard regarding it and not finding it, is enough to remove the unnecessary hinting instead there needs to be another feature like error and warning summary etc.
So all these complaints seem to stem from a Warning that reads like a Rule, which causes confusion. I just looked at the page that allows customising the warning and you can apparently change the text of the warning as well as the number that triggers the warning. (I had this come up for a function that was assigning some values from one array to another array. Thirty elements to assign, at least 30 lines in the function, no way to shorten it, the warning triggered at 30 lines). Changing the text to something like: High number of lines in Method makes much more sense, and doesn't send new programmers looking for the specifications. Personally, I turn it off, if I don't know by now (programming since 1979), I should give up.
I know I am a little [very] late to the party; but I just came across this warning in Netbeans 8.2 and I have to mirror some of the other comments by saying that this hint seems misleading. I take issue with some aspects of this warning; first and foremost is the language used. This 'hint' is shown as a 'Warning', and the message reads "Method length is [21..] Lines (20 allowed)" (for Function Declaration). This seems to imply that the simple act of having a long method or class can have an adverse effect on the way the code complies/runs. This is simply not true, and I do not think this is the message the original author, or any subsequent authors, intended to send. I think the intent of this hint is to suggest that creating long classes, methods, interfaces or traits will have adverse effects on the maintainability and extensibility of the code base. This can be a valid argument, even if some programmers may disagree with that assertion. Therefore, the simple act of changing the language used can greatly increase the validity of this hint. If the hint was shown as a 'Suggestion on the current line' by default and the message read "Method length is [21..] (20 suggested)" it would correctly convey that this is a suggestion imposed by the IDE (and the authors behind it), not a 'Warning' based on language or compiler restrictions. --- That being said, I also happen to be one of the programmers that disagree with the assertion that long classes or methods will have an adverse effect on extensibility. I think it can have an adverse effect in certain cases, but it incorrect to assume that this will be true in all cases. A simple example of a case where this is simply not true (as mentioned by danielc1657) is a switch statement; which can easily create a function that grows past 20 lines when you consider each 'case' is usually a minimum of three lines (the 'case' statement, the subsequent result statement, and a 'break' statement). For this reason, I have to agree with the other commenters and say that this hint should be disabled by default. It is a nice feature to have for those who want to impose the restriction on themselves, or possibly imposed by a project manager. But, even with the changes in the language used that I suggested, it seems to clutter the IDE with unnecessary hints. --- I have already disabled the feature, but I hope the community and authors can agree that the changes I suggested are for the best.