[yast-devel] Again: 98% of "undefined method" errors have nothing to do with static typing
This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting. Let me say it again: 98% of the "undefined method `xxx' for nil:NilClass" errors are NOT related AT ALL to Ruby being dynamically typed and would NOT be prevented by the usage of a statically typed language. And the other side of the same recurring coin - we don't write unit tests as a replacement for the compiler checks. That's not the point, the goal or the intention of the unit tests. This time I will try to explain it with an example (something that already has been done, but I just felt impelled to do it one more time). Let's say you have this Ruby method that returns an object of type Device or nil if the device was not found find_device_by_name(name) And then you write this code dev = find_device_by_name("/dev/sda") puts dev.size If there is no /dev/sda that will result in one of those "undefined method `size` for nil:NilClass" that some people hate so much. Did it happen because Ruby is dynamically typed? NOT AT ALL. It happened because you didn't check for the situation in which the device is not there with some code like this. dev = find_device_by_name("/dev/sda") if dev puts dev.size else puts "No such device" end Let's do the same in an hypothetical typed Ruby in which there is nothing like nil. Now your find_device_by_name method will raise a NotFound exception instead of returning nil if the device is not there (the approach we use in statically typed languages). The first example will still fail, now with an uncaught NotFound exception. The static type checking performed by the compiler didn't save us from THE DEVELOPER ERROR and the result is pretty much the same - an exception thrown in the user's face. In this case, the correct solution is pretty similar to the real (dynamic) Ruby one begin dev = find_device_by_name("/dev/sda") puts dev.size rescue NotFound puts "No such device" end Both errors are the same error, a programmer error. Both errors happen during runtime, just the raised exception is different. In Ruby, the error is revealed in a slightly different way that it would be revealed in a static language. But that's the whole difference. Static type checking would not save you in 98% of the cases. What can save us in both cases? Comprehensive unit tests. Because they have a completely different goal from the checks performed by the compiler and they should spot a different kind of errors. Of course, that implies that whoever is writing the tests thinks in all possible situations (like the device not being there) and covers those situations with tests. That's why unit tests are a must in both dynamically and statically typed languages. If you think in your unit tests as a replacement of the static type checking... you will very likely not write the right unit tests. And please, stop assuming that every single "undefined method" error is caused by a missing type check. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 12/13/2017 12:18 AM, Ancor Gonzalez Sosa wrote:
This is probably the... [...]> stop assuming that every single "undefined method" error is caused by a missing type check.
Just to clarify. The 98% is a completely made up number. It was just my way to say "a huge majority of cases". The number is not the result of any serious statistics or any study. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, 2017-12-13 at 00:18 +0100, Ancor Gonzalez Sosa wrote:
This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.
Discussing is (usually) fun :) [..]
Let's do the same in an hypothetical typed Ruby in which there is nothing like nil. Now your find_device_by_name method will raise a NotFound exception instead of returning nil if the device is not there (the approach we use in statically typed languages).
Instead of throwing (and rescuing exceptions) all over the place (an approach I dislike), some typed languages offer a better way to deal with these situations: option types[1]. In a nutshell, an option type represents a value that could (or not) be nil. Lately I've been playing around with Elm and Rust and, in both cases, the compiler will complain if you do not write code to handle the "None" case. You can check some Rust[2] example if you are interested. And it looks like C++17 already support such a feature (although we are not using it IIRC). As a side note (about throwing exceptions), I prefer having "find_by_device_name" and "find_by_device_name!" methods. The former would return 'nil' if a device is not found and the latter would raise an exception. The idea is that the user of the library could decide how important is not finding a device, as it might be (or not) a critical error. But that's a different discussion. [..]
Both errors are the same error, a programmer error. Both errors happen during runtime, just the raised exception is different. In Ruby, the error is revealed in a slightly different way that it would be revealed in a static language. But that's the whole difference. Static type checking would not save you in 98% of the cases.
Proper static type checking might help in those situations.
What can save us in both cases? Comprehensive unit tests. Because they have a completely different goal from the checks performed by the compiler and they should spot a different kind of errors. Of course, that implies that whoever is writing the tests thinks in all possible situations (like the device not being there) and covers those situations with tests. That's why unit tests are a must in both dynamically and statically typed languages.
I absolutely agree. [..] On the other hand, I've been taking care of YaST incoming bugs these days and I can hardly remember an "internal error" caused by some out- of-control nil value. Most of our bugs have nothing to do with type checking. If main argument against Ruby is that it lacks of type checking, I can live with that :) Regards, Imo [1] https://en.wikipedia.org/wiki/Option_type [2] https://rustbyexample.com/std/option.html -- Imobach González Sosa YaST team at SUSE LINUX GmbH Blog: https://imobachgs.github.io/ Twitter: @imobachgs
On Wed, Dec 13, 2017 at 07:36:19AM +0000, Imobach González Sosa wrote:
On Wed, 2017-12-13 at 00:18 +0100, Ancor Gonzalez Sosa wrote:
This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.
Discussing is (usually) fun :)
[..]
Let's do the same in an hypothetical typed Ruby in which there is nothing like nil. Now your find_device_by_name method will raise a NotFound exception instead of returning nil if the device is not there (the approach we use in statically typed languages).
Instead of throwing (and rescuing exceptions) all over the place (an approach I dislike), some typed languages offer a better way to deal with these situations: option types[1].
In a nutshell, an option type represents a value that could (or not) be nil. Lately I've been playing around with Elm and Rust and, in both cases, the compiler will complain if you do not write code to handle the "None" case. You can check some Rust[2] example if you are interested.
And it looks like C++17 already support such a feature (although we are not using it IIRC).
I have that idea in mind (https://trello.com/c/Kjq05SDY/119-use-stdoptional-c17) but C++17 in SLE 15 is experimental.
As a side note (about throwing exceptions), I prefer having "find_by_device_name" and "find_by_device_name!" methods. The former would return 'nil' if a device is not found and the latter would raise an exception.
I always though the function with ! modifies the argument while the one without returns a modified object.
On the other hand, I've been taking care of YaST incoming bugs these days and I can hardly remember an "internal error" caused by some out- of-control nil value.
I can remember bugs of the kind "undefined method xxx for nilClass". And I can also remember bugs where a function name was simply mistyped. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
V Wed, 13 Dec 2017 10:04:24 +0100 Arvin Schnell <aschnell@suse.com> napsáno:
On Wed, Dec 13, 2017 at 07:36:19AM +0000, Imobach González Sosa wrote:
On Wed, 2017-12-13 at 00:18 +0100, Ancor Gonzalez Sosa wrote:
This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.
Discussing is (usually) fun :)
[..]
Let's do the same in an hypothetical typed Ruby in which there is nothing like nil. Now your find_device_by_name method will raise a NotFound exception instead of returning nil if the device is not there (the approach we use in statically typed languages).
Instead of throwing (and rescuing exceptions) all over the place (an approach I dislike), some typed languages offer a better way to deal with these situations: option types[1].
In a nutshell, an option type represents a value that could (or not) be nil. Lately I've been playing around with Elm and Rust and, in both cases, the compiler will complain if you do not write code to handle the "None" case. You can check some Rust[2] example if you are interested.
And it looks like C++17 already support such a feature (although we are not using it IIRC).
I have that idea in mind (https://trello.com/c/Kjq05SDY/119-use-stdoptional-c17) but C++17 in SLE 15 is experimental.
As a side note (about throwing exceptions), I prefer having "find_by_device_name" and "find_by_device_name!" methods. The former would return 'nil' if a device is not found and the latter would raise an exception.
I always though the function with ! modifies the argument while the one without returns a modified object.
Well, it is only convention and such convention specifies that version with ! is "dangerous" function that e.g. modify object that someone else can use, raise exception if something is missing and so on. It is mainly used to distract between two versions of call ( e.g. similar to some degree to const and non-const versions of method in C++ ).
On the other hand, I've been taking care of YaST incoming bugs these days and I can hardly remember an "internal error" caused by some out- of-control nil value.
I can remember bugs of the kind "undefined method xxx for nilClass".
sadly same kind of errors can happen also in ycp and c++ ( calling something on nil ) and at least for me result is the best from these three ( ycp silently do nothing and c++ segfault ). If we want to prevent this kind of errors, then rust is answer.
And I can also remember bugs where a function name was simply mistyped.
agreed. It is trade-off for dynamic nature of ruby. And for mistyped function names unit tests is currently only answer. In future ruby type inference can help.
ciao Arvin
Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 12/13/2017 10:04 AM, Arvin Schnell wrote:
On Wed, Dec 13, 2017 at 07:36:19AM +0000, Imobach González Sosa wrote:
On Wed, 2017-12-13 at 00:18 +0100, Ancor Gonzalez Sosa wrote:
I always though the function with ! modifies the argument while the one without returns a modified object.
On the other hand, I've been taking care of YaST incoming bugs these days and I can hardly remember an "internal error" caused by some out- of-control nil value.
I can remember bugs of the kind "undefined method xxx for nilClass".
Sure they happen, although different people may have different perceptions on how often. But my point was - please, stop identifying every single one of those bugs with a lack of type checking. Most of the times they mean something else.
And I can also remember bugs where a function name was simply mistyped.
Yes. That has happened. And yes, a more static language would have avoided that at compilation time. But it happens VERY seldom. Maybe twice a year for the whole YaST. This is the very small subset of all the "undefined method xxx" that are indeed a consequence of Ruby dynamic approach. Don't put all the other bugs in the same basket just because the text of the exception looks similar. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, Dec 13, 2017 at 12:18:16AM +0100, Ancor Gonzalez Sosa wrote:
This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.
Let me say it again: 98% of the "undefined method `xxx' for nil:NilClass" errors are NOT related AT ALL to Ruby being dynamically typed and would NOT be prevented by the usage of a statically typed language.
And the other side of the same recurring coin - we don't write unit tests as a replacement for the compiler checks. That's not the point, the goal or the intention of the unit tests.
This time I will try to explain it with an example (something that already has been done, but I just felt impelled to do it one more time).
Let's say you have this Ruby method that returns an object of type Device or nil if the device was not found
find_device_by_name(name)
And then you write this code
dev = find_device_by_name("/dev/sda") puts dev.size
If there is no /dev/sda that will result in one of those "undefined method `size` for nil:NilClass" that some people hate so much. Did it happen because Ruby is dynamically typed? NOT AT ALL. It happened because you didn't check for the situation in which the device is not there with some code like this.
dev = find_device_by_name("/dev/sda") if dev puts dev.size else puts "No such device" end
Let's do the same in an hypothetical typed Ruby in which there is nothing like nil. Now your find_device_by_name method will raise a NotFound exception instead of returning nil if the device is not there (the approach we use in statically typed languages).
The first example will still fail, now with an uncaught NotFound exception. The static type checking performed by the compiler didn't save us from THE DEVELOPER ERROR and the result is pretty much the same - an exception thrown in the user's face.
I think you are mixing static typing and static code analysis. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
V Wed, 13 Dec 2017 09:47:13 +0100 Arvin Schnell <aschnell@suse.com> napsáno:
On Wed, Dec 13, 2017 at 12:18:16AM +0100, Ancor Gonzalez Sosa wrote:
This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.
Let me say it again: 98% of the "undefined method `xxx' for nil:NilClass" errors are NOT related AT ALL to Ruby being dynamically typed and would NOT be prevented by the usage of a statically typed language.
I think you are mixing static typing and static code analysis.
ciao Arvin
Well, it is a bit related as static code analysis strength is related to rigidness of language. And actually even c++ have quite weak static code analysis. That is reason why decade ago java become more popular as it have better analysis ability and now I think number one for this purpose is Rust. And on bright side, ruby also plan to have type inference, but of course it cannot be so strong as in very rigid languages as rust or java. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, Dec 13, 2017 at 10:14:42AM +0100, Josef Reidinger wrote:
V Wed, 13 Dec 2017 09:47:13 +0100 Arvin Schnell <aschnell@suse.com> napsáno:
On Wed, Dec 13, 2017 at 12:18:16AM +0100, Ancor Gonzalez Sosa wrote:
This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.
Let me say it again: 98% of the "undefined method `xxx' for nil:NilClass" errors are NOT related AT ALL to Ruby being dynamically typed and would NOT be prevented by the usage of a statically typed language.
I think you are mixing static typing and static code analysis.
ciao Arvin
Well, it is a bit related as static code analysis strength is related to rigidness of language. And actually even c++ have quite weak static code analysis.
Not only the compiler can do static code analysis. Other tools do much more, e.g. coverity. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
V Wed, 13 Dec 2017 10:31:32 +0100 Arvin Schnell <aschnell@suse.com> napsáno:
On Wed, Dec 13, 2017 at 10:14:42AM +0100, Josef Reidinger wrote:
V Wed, 13 Dec 2017 09:47:13 +0100 Arvin Schnell <aschnell@suse.com> napsáno:
On Wed, Dec 13, 2017 at 12:18:16AM +0100, Ancor Gonzalez Sosa wrote:
This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.
Let me say it again: 98% of the "undefined method `xxx' for nil:NilClass" errors are NOT related AT ALL to Ruby being dynamically typed and would NOT be prevented by the usage of a statically typed language.
I think you are mixing static typing and static code analysis.
ciao Arvin
Well, it is a bit related as static code analysis strength is related to rigidness of language. And actually even c++ have quite weak static code analysis.
Not only the compiler can do static code analysis. Other tools do much more, e.g. coverity.
ciao Arvin
How does coverity or other handle pointers in C++? I think it is similar kind of issue as ruby have for static analysis. Any pointer can be NULL or invalid address and similar in ruby anything can be nil. I know that mvidner trying rubylint and it was quite tricky. So if coverity can deal with such issue, we can check how it is done and can check is someone try similar approach for ruby and it can really helps us. Thanks Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 13.12.2017 10:35, Josef Reidinger wrote:
V Wed, 13 Dec 2017 10:31:32 +0100 Arvin Schnell <aschnell@suse.com> napsáno:
On Wed, Dec 13, 2017 at 10:14:42AM +0100, Josef Reidinger wrote:
V Wed, 13 Dec 2017 09:47:13 +0100 Arvin Schnell <aschnell@suse.com> napsáno:
On Wed, Dec 13, 2017 at 12:18:16AM +0100, Ancor Gonzalez Sosa wrote:
This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.
Let me say it again: 98% of the "undefined method `xxx' for nil:NilClass" errors are NOT related AT ALL to Ruby being dynamically typed and would NOT be prevented by the usage of a statically typed language.
I think you are mixing static typing and static code analysis.
ciao Arvin
Well, it is a bit related as static code analysis strength is related to rigidness of language. And actually even c++ have quite weak static code analysis.
Not only the compiler can do static code analysis. Other tools do much more, e.g. coverity.
ciao Arvin
How does coverity or other handle pointers in C++? I think it is similar kind of issue as ruby have for static analysis. Any pointer can be NULL or invalid address and similar in ruby anything can be nil. I know that mvidner trying rubylint and it was quite tricky. So if coverity can deal with such issue, we can check how it is done and can check is someone try similar approach for ruby and it can really helps us.
In C++, you can follow the approach which Michael did when developing libzypp: Only use plain pointers for the minimum time needed to convert them to various kinds of smart pointers which the boost library offered. This policy somehow mitigated the problem with pointers. Jiri -- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Krizikova 148/34 tel: +420 284 084 659 186 00 Praha 8 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, Dec 13, 2017 at 10:54:48AM +0100, Jiri Srain wrote:
In C++, you can follow the approach which Michael did when developing libzypp: Only use plain pointers for the minimum time needed to convert them to various kinds of smart pointers which the boost library offered. This policy somehow mitigated the problem with pointers.
Those smart pointers are standardised in C++11 and of course also used in libstorage-ng. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
V Wed, 13 Dec 2017 10:54:48 +0100 Jiri Srain <jsrain@suse.cz> napsáno:
On 13.12.2017 10:35, Josef Reidinger wrote:
V Wed, 13 Dec 2017 10:31:32 +0100 Arvin Schnell <aschnell@suse.com> napsáno:
On Wed, Dec 13, 2017 at 10:14:42AM +0100, Josef Reidinger wrote:
V Wed, 13 Dec 2017 09:47:13 +0100 Arvin Schnell <aschnell@suse.com> napsáno:
On Wed, Dec 13, 2017 at 12:18:16AM +0100, Ancor Gonzalez Sosa wrote:
This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.
Let me say it again: 98% of the "undefined method `xxx' for nil:NilClass" errors are NOT related AT ALL to Ruby being dynamically typed and would NOT be prevented by the usage of a statically typed language.
I think you are mixing static typing and static code analysis.
ciao Arvin
Well, it is a bit related as static code analysis strength is related to rigidness of language. And actually even c++ have quite weak static code analysis.
Not only the compiler can do static code analysis. Other tools do much more, e.g. coverity.
ciao Arvin
How does coverity or other handle pointers in C++? I think it is similar kind of issue as ruby have for static analysis. Any pointer can be NULL or invalid address and similar in ruby anything can be nil. I know that mvidner trying rubylint and it was quite tricky. So if coverity can deal with such issue, we can check how it is done and can check is someone try similar approach for ruby and it can really helps us.
In C++, you can follow the approach which Michael did when developing libzypp: Only use plain pointers for the minimum time needed to convert them to various kinds of smart pointers which the boost library offered. This policy somehow mitigated the problem with pointers.
Jiri
In fact it does not help always. E.g. now with libstorage-ng is there autoptr, but still we get segfaults when device graph is changed as these autoptr is set to NULL and create segfaults. So as long as program can have object that is no longer valid, you have problem to statically detect it as it means you have to understand code flow to decide if object is valid or not, which is really hard task for analyzer. As long as all objects are valid for its whole lifetime and no-one holds it after it is not valid it helps. BTW libzypp use quite heavily Null object pattern exactly to not return nil and instead this null object. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 13.12.2017 11:11, Josef Reidinger wrote:
In fact it does not help always. E.g. now with libstorage-ng is there autoptr, but still we get segfaults when device graph is changed as these autoptr is set to NULL and create segfaults.
Sure, if a library is used wrong, you can still get a lot of nasty errors. If you store pointers that you don't own, their content can always become invalid if you don't watch out for their lifetime. For C++ code that I write, I always try to document the expected lifetime of pointers that are returned, and of course also who owns that object and who is consequently responsible for deleting it. This is a class of problems that languages using garbage collection (not only Ruby, but also Java, JavaScript and many more) don't have (unless you have circular dependencies where object instances refer to each other, even though there is no more outside reference to any of them anymore; this is hard to detect). Kind regards -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 13.12.2017 10:35, Josef Reidinger wrote:
How does coverity or other handle pointers in C++? I think it is similar kind of issue as ruby have for static analysis. Any pointer can be NULL or invalid address and similar in ruby anything can be nil.
Coverity will (among a lot of other things) complain if you use a pointer that you got e.g. as a function parameter and didn't check it first before dereferencing it. Sometimes this will result in false positives, but an extra check is cheap and can indeed prevent a segfault. Kind regards -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
V Mon, 18 Dec 2017 11:57:49 +0100 Stefan Hundhammer <shundhammer@suse.de> napsáno:
On 13.12.2017 10:35, Josef Reidinger wrote:
How does coverity or other handle pointers in C++? I think it is similar kind of issue as ruby have for static analysis. Any pointer can be NULL or invalid address and similar in ruby anything can be nil.
Coverity will (among a lot of other things) complain if you use a pointer that you got e.g. as a function parameter and didn't check it first before dereferencing it. Sometimes this will result in false positives, but an extra check is cheap and can indeed prevent a segfault.
Kind regards
If I get it correctly coverity report when pointer is assigned from unknown source ( e.g. that function parameter or its result ) and not checked? So it basically would like to see stuff a = method(); if (a) b = *a; or void m(char *c) { if !c return; ... } I think check like this can be done also for ruby, but I am not sure how much it will affect current code, because some methods can live with nil and some method require to not get it ( e.g. some private methods ). So I expect huge amount of false positives. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Ancor, this is so great explanation that it either deserves a blog entry or even an article in Linux Magazine :) You should do something about it :D Thanks Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (7)
-
Ancor Gonzalez Sosa -
Arvin Schnell -
Imobach González Sosa -
Jiri Srain -
Josef Reidinger -
Lukas Ocilka -
Stefan Hundhammer