Access granted!
-
Multiple returns are not gotos and are not a bad design practice. Guard conditions are actually favored over nesting if's
-
It is not necessarily a horror if it was found in a debug/dev build. I do it in similar way, too. Of course you have to remember to remove it for release builds (or use #if DEBUG clause). Note: don't use GOTO (multiple returns are gotos too)
Greetings - Jacek
This is Java code. Returning a value "null" is not the best idea, but it's a invalid value one can identify as such. I actually often return values in that way:
switch(key){
case x: return a;
case y: return b;
default: return null;
}It's pretty handsome and easy to maintain. regards Torsten
I never finish anyth...
-
This is Java code. Returning a value "null" is not the best idea, but it's a invalid value one can identify as such. I actually often return values in that way:
switch(key){
case x: return a;
case y: return b;
default: return null;
}It's pretty handsome and easy to maintain. regards Torsten
I never finish anyth...
Since the
Nullable<>thing was introduced, it seems that MS encourages developers to usenullas a "special" and possibly meaningful value. Personally I don't have a strong opinion on that, but often after I declared sth asT?I had to change it toTdue to interopability issues and too many not-null checks.Greetings - Jacek
-
You are right about guard condition. My note was general -- do not use 'return' like 'goto' (jumping from the middle of method).
Greetings - Jacek
That depends a lot on your language. Its a common (and safe) technique in C++ using RAII techniques.
-
Ever wondered how those password dialogs work like? Here is a small sneak under the hood:
final PasswordDialog pwd = new PasswordDialog(ApplicationWorkbenchWindowAdvisor.getShell());
if (pwd.open() == Window.OK) {
ConnectionManager.password = AccountManager.getGeneralStore().getString(
"UA.Account.Security.sec_pass"
);
}
else {
return null;
}Security at it's best. At least does the string from the preferences store just fit if you've got the right username :omg: regards Torsten
I never finish anyth...
If you're going to say something is bad, could you at least explain to rookie doofuses like me why it's bad? Due to my lack of experience, I look at your code and I have no idea what the problem is. Furthermore, none of the comments here helps. Explain to me like I'm a complete idiot (which I occasionally am).
-
If you're going to say something is bad, could you at least explain to rookie doofuses like me why it's bad? Due to my lack of experience, I look at your code and I have no idea what the problem is. Furthermore, none of the comments here helps. Explain to me like I'm a complete idiot (which I occasionally am).
Seems to me what they're talking about is the use of null as a return value. "They" don't seem to like it. Seems to me there's lots of "personal preferences" in a lot of threads found on this forum. To me, returning null is just fine; as an old database guy, null proves to be a very handy and very real data type/value.
-
If you're going to say something is bad, could you at least explain to rookie doofuses like me why it's bad? Due to my lack of experience, I look at your code and I have no idea what the problem is. Furthermore, none of the comments here helps. Explain to me like I'm a complete idiot (which I occasionally am).
As to the return thing... Camp 1 says, when writing a method/function, you should have one entry point and one exit point. For languages that use return to exit the method, this implies a single return at the end of the method/function. Using this model sometimes involves multiple nested if statements. Camp 2 might say I like to validate all preconditions and immediately return if something appears amiss, but then I have one return at the bottom for the real answer. Camp 3 might say, I use assert() for things like Camp 2 does with returns, but I still have one return at the bottom. Camp 4 might say, just throw a return in wherever it makes sense. Camp X, might pick and choose what they want from other camps.
-
As to the return thing... Camp 1 says, when writing a method/function, you should have one entry point and one exit point. For languages that use return to exit the method, this implies a single return at the end of the method/function. Using this model sometimes involves multiple nested if statements. Camp 2 might say I like to validate all preconditions and immediately return if something appears amiss, but then I have one return at the bottom for the real answer. Camp 3 might say, I use assert() for things like Camp 2 does with returns, but I still have one return at the bottom. Camp 4 might say, just throw a return in wherever it makes sense. Camp X, might pick and choose what they want from other camps.
-
If you're going to say something is bad, could you at least explain to rookie doofuses like me why it's bad? Due to my lack of experience, I look at your code and I have no idea what the problem is. Furthermore, none of the comments here helps. Explain to me like I'm a complete idiot (which I occasionally am).
There is a dialog opened - a password-dialog. When it returns OK (dialog is confirmed / left with "OK" button) the app not uses the entered password, but refers to some preference stored before. Passwords which are entered by the user in a customers application, may never be written to files - no matter if ASCII, binary or whatever. It took me a couple of hours to verify that no password is stored in that application and no password is read at any time. A password must always be kept in the RAM and disposed when the application is shut down. Also the stored password in the database should be encrypted. regards Torsten
I never finish anyth...
-
There is a dialog opened - a password-dialog. When it returns OK (dialog is confirmed / left with "OK" button) the app not uses the entered password, but refers to some preference stored before. Passwords which are entered by the user in a customers application, may never be written to files - no matter if ASCII, binary or whatever. It took me a couple of hours to verify that no password is stored in that application and no password is read at any time. A password must always be kept in the RAM and disposed when the application is shut down. Also the stored password in the database should be encrypted. regards Torsten
I never finish anyth...
-
There is a dialog opened - a password-dialog. When it returns OK (dialog is confirmed / left with "OK" button) the app not uses the entered password, but refers to some preference stored before. Passwords which are entered by the user in a customers application, may never be written to files - no matter if ASCII, binary or whatever. It took me a couple of hours to verify that no password is stored in that application and no password is read at any time. A password must always be kept in the RAM and disposed when the application is shut down. Also the stored password in the database should be encrypted. regards Torsten
I never finish anyth...
-
If you're really worried about security, don't forget to overwrite that password in RAM immediately when you're done with it. Wouldn't want that cleartext password to get paged to disk.
patbob
You'd have to physically find it first.