userid=="administrator"
-
if (Session["UserID"] != null && Session["UserID"].ToString() == "administrator") { adminRight = "W"; } return adminRight; well first of all if it's UserID i expect it to be number, ok somebody squeezed here 'administrator' nice job. Another thing is if userID == 'administrator' it cant be in any case at the same time null.
-
if (Session["UserID"] != null && Session["UserID"].ToString() == "administrator") { adminRight = "W"; } return adminRight; well first of all if it's UserID i expect it to be number, ok somebody squeezed here 'administrator' nice job. Another thing is if userID == 'administrator' it cant be in any case at the same time null.
The rest of the code may be pretty dumb but checking for null first is good coding. Of course, you wouldn't realise that if you were VB coder.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
-
if (Session["UserID"] != null && Session["UserID"].ToString() == "administrator") { adminRight = "W"; } return adminRight; well first of all if it's UserID i expect it to be number, ok somebody squeezed here 'administrator' nice job. Another thing is if userID == 'administrator' it cant be in any case at the same time null.
Tadas Budvytis wrote:
well first of all if it's UserID i expect it to be number,
Why? Don't you remember 'ALFKI' from the Northwind?
Tadas Budvytis wrote:
Another thing is if userID == 'administrator' it cant be in any case at the same time null.
Session["UserID"] != nullcriteria is required because if you code thatiflike thisif (Session["UserID"].ToString() == "administrator") ..., it will throw an exception if the user is not logged in. There's no real horror here.Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they're sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. (Charles M Strauss)
-
if (Session["UserID"] != null && Session["UserID"].ToString() == "administrator") { adminRight = "W"; } return adminRight; well first of all if it's UserID i expect it to be number, ok somebody squeezed here 'administrator' nice job. Another thing is if userID == 'administrator' it cant be in any case at the same time null.
for some reason i was sure that in C# oposed to C+ there are no garantees in what order (if) conditions will be compiled and executed later. Seems it's done in good way. That's good. but UserID='administrator' this wrong, i can understand that if userID is a userCODE like 'BDWR' or so but in our case in 99% it's used as a number.
-
for some reason i was sure that in C# oposed to C+ there are no garantees in what order (if) conditions will be compiled and executed later. Seems it's done in good way. That's good. but UserID='administrator' this wrong, i can understand that if userID is a userCODE like 'BDWR' or so but in our case in 99% it's used as a number.
I'm pretty sure all C# boolean evaluations (including
if) are short-circuiting, so I don't see how the block could be evaluated out of order.Imagine that you are hired to build a bridge over a river. The river gets slightly wider every day; sometimes it shrinks but nobody can predict when. Your contract says you can't use concrete or steel - the client only provides timber and cut stone (but won't tell you what kind). Gravity changes from hour to hour, as does the viscosity of air. Your only tools are a hacksaw, a chainsaw, a rubber mallet, and a length of rope. Welcome to my world. -Me explaining my job to an engineer
-
I'm pretty sure all C# boolean evaluations (including
if) are short-circuiting, so I don't see how the block could be evaluated out of order.Imagine that you are hired to build a bridge over a river. The river gets slightly wider every day; sometimes it shrinks but nobody can predict when. Your contract says you can't use concrete or steel - the client only provides timber and cut stone (but won't tell you what kind). Gravity changes from hour to hour, as does the viscosity of air. Your only tools are a hacksaw, a chainsaw, a rubber mallet, and a length of rope. Welcome to my world. -Me explaining my job to an engineer
Simply called "lazy evaluation". BTW, great signature! :)
Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they're sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. (Charles M Strauss)
-
Simply called "lazy evaluation". BTW, great signature! :)
Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they're sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. (Charles M Strauss)
Yours isn't so bad yourself! :-D
Imagine that you are hired to build a bridge over a river. The river gets slightly wider every day; sometimes it shrinks but nobody can predict when. Your contract says you can't use concrete or steel - the client only provides timber and cut stone (but won't tell you what kind). Gravity changes from hour to hour, as does the viscosity of air. Your only tools are a hacksaw, a chainsaw, a rubber mallet, and a length of rope. Welcome to my world. -Me explaining my job to an engineer
-
I'm pretty sure all C# boolean evaluations (including
if) are short-circuiting, so I don't see how the block could be evaluated out of order.Imagine that you are hired to build a bridge over a river. The river gets slightly wider every day; sometimes it shrinks but nobody can predict when. Your contract says you can't use concrete or steel - the client only provides timber and cut stone (but won't tell you what kind). Gravity changes from hour to hour, as does the viscosity of air. Your only tools are a hacksaw, a chainsaw, a rubber mallet, and a length of rope. Welcome to my world. -Me explaining my job to an engineer
Robert Royall wrote:
I'm pretty sure all C# boolean evaluations (including if) are short-circuiting,
Yea thats correct.
Mark Brock Click here to view my blog
-
if (Session["UserID"] != null && Session["UserID"].ToString() == "administrator") { adminRight = "W"; } return adminRight; well first of all if it's UserID i expect it to be number, ok somebody squeezed here 'administrator' nice job. Another thing is if userID == 'administrator' it cant be in any case at the same time null.
You'll get a runtime error calling ToString on a null reference, and the null check avoids this.
Semicolons: The number one seller of ostomy bags world wide. - dan neely
-
Yours isn't so bad yourself! :-D
Imagine that you are hired to build a bridge over a river. The river gets slightly wider every day; sometimes it shrinks but nobody can predict when. Your contract says you can't use concrete or steel - the client only provides timber and cut stone (but won't tell you what kind). Gravity changes from hour to hour, as does the viscosity of air. Your only tools are a hacksaw, a chainsaw, a rubber mallet, and a length of rope. Welcome to my world. -Me explaining my job to an engineer
:laugh:
Semicolons: The number one seller of ostomy bags world wide. - dan neely
-
for some reason i was sure that in C# oposed to C+ there are no garantees in what order (if) conditions will be compiled and executed later. Seems it's done in good way. That's good. but UserID='administrator' this wrong, i can understand that if userID is a userCODE like 'BDWR' or so but in our case in 99% it's used as a number.
Tadas Budvytis wrote:
99% it's used as a num
I doubt that very much. Would you perform mathematical operations on it?
-
if (Session["UserID"] != null && Session["UserID"].ToString() == "administrator") { adminRight = "W"; } return adminRight; well first of all if it's UserID i expect it to be number, ok somebody squeezed here 'administrator' nice job. Another thing is if userID == 'administrator' it cant be in any case at the same time null.
No horror here. :confused:
Tadas Budvytis wrote:
well first of all if it's UserID i expect it to be number
ID is shorter for IDentification, it can be numerical value, GUID, string... almost anything programmer wants. It's common thing for naming primary keys in RDB-s with Something + ID and usually these ID-s are integers, but that convention can be misleading for beginners. Sometimes it's better to use other types, string or guid for instance and different naming conventions.
modified on Monday, June 2, 2008 9:05 AM
-
for some reason i was sure that in C# oposed to C+ there are no garantees in what order (if) conditions will be compiled and executed later. Seems it's done in good way. That's good. but UserID='administrator' this wrong, i can understand that if userID is a userCODE like 'BDWR' or so but in our case in 99% it's used as a number.
I had the same objection to this while going through some code with the boss many years ago. I always checked for null separately before doing anything else. He did it just the same way like in the code here. He argued that the check for null values is always done first and does not run into the second term if the value is indeed null. This may not be sound proof, but the entire code was full of this and we never had any problems because of that.
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'. I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.