|
Wait, your supervisor had declared that this task was impossible (according to Peter Norton's book) and then you tried it successfully, which proved that you were arrogant rather than... smart and determined?
Real nice. Perhaps she should be working behind a library service desk somewhere
|
|
|
|
|
It would have been nice, but in her eyes, I showed her up. Being an insecure control freak she was always afraid I was after her job. She never accepted the idea that I had no interest in her job, I had my own career path I was interested in.
But don't get me started. I and my colleagues who had the misfortune of working under her have HOURS of stories about her.
Psychosis at 10
Film at 11
|
|
|
|
|
rahultandon1000 wrote: Code from one of my junior :-> ---- this is
Page-A.aspx
<SPAN class=code-keyword>protected</SPAN> <SPAN class=code-keyword>void</SPAN> Page_Load(<SPAN class=code-keyword>object</SPAN> sender, EventArgs e)
{
Response.Redirect(<SPAN class=code-string>"</SPAN><SPAN class=code-string>Page-A.aspx"</SPAN>);
}
for (int i = 0; i < 101; i++) Blackboard.WriteLine("I must not use unterminated recursion.");
|
|
|
|
|
Surely you mean
for (int i = 100; i >= 0; i++) Blackboard.WriteLine("I must not use unterminated recursion.");
|
|
|
|
|
Or even...
void F() {
Blackboard.WriteLine("I must not use unterminated recursion");
F();
}
(Your version was unterminated iteration)
|
|
|
|
|
rahultandon1000 wrote: it keeps browser busy to keep loading the same page
Finally someone who knows how to get the fullest from the newest i7 uber-core computers with really very fast internet connections!
It's an OO world.
|
|
|
|
|
rahultandon1000 wrote: protected void Page_Load(object sender, EventArgs e)
{
Response.Redirect("Page-A.aspx");
}
Page-A.aspx .. Is this the real page name or you have modified it ?
|
|
|
|
|
If it's the real name, it's a bigger horror then the relatively small mistake of redirecting to the wrong page...
|
|
|
|
|
He stated earlier that it's a login loop, not as simple as what he posted, so I imagine the page is actually Login.aspx or similar. (Which is a relatively easy mistake to make with how login protection works ... just needs you to accidentally put an authorisation check on the login page.)
|
|
|
|
|
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
regards
Torsten
I never finish anyth...
|
|
|
|
|
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
|
|
|
|
|
Multiple returns are not gotos and are not a bad design practice.
Guard conditions are actually favored over nesting if's
|
|
|
|
|
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.
|
|
|
|
|
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 use null as a "special" and possibly meaningful value.
Personally I don't have a strong opinion on that, but often after I declared sth as T? I had to change it to T due to interopability issues and too many not-null checks.
Greetings - Jacek
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
|
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...
|
|
|
|
|
Wow, from looking at that piece of code, I'd never know anything was awry. Without me looking up a bunch of APIs, I'd never have a clue it was doing any of that wrong.
|
|
|
|
|
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.
|
|
|
|
|
I have only just found out what this would do:
That line was causing one of our webpages to load extremely slow, and I wasn't sure why. It seems a control placed inside of an HTML comment in an ASP.NET page will actually be executed (the control was in development and was very slow). So the HTML that gets output based on the above code might be:
<!--
Using a server-side comment, on the other hand, does not cause this problem:
<%----%>
That will not render to any HTML (as expected). I suppose it makes sense, but still had me stumped for a bit.
|
|
|
|