|
I personally use x (and y and z for nested loops - if you nest more than two levels, you need to redesign), I make it unsigned (unless there's a specific reason to use signed) because that more accurately models the real world, and I use the prefix form of the increment operator because it's potentially more efficient. So my canonical form of that construct would be:
for (unsigned x = 0; x < size; ++x)
And yes, some of my co-workers make fun of me. The ones who spend twice as much time debugging their code as I do debugging mine.
|
|
|
|
|
I use
for (int r = 0; r < size; i++)
because
1) "r" is directly next to "t" when I type "int[spaceBar]r", typing flow is much nicer;
2) "r" is on my left-hand vs. the right-hand, so when I type "someArray[r]" I type faster as my fingers type in sync with one another; seriously, try it for a week and you'll see it flows much better;
3) "r" means "repeat" (or "record") in my brain
4) using i reminds me of when I flunked Spanish... example: iFlunked!
5) I got sick of iThisCrap, iThatCrap, iWTF;
.... - even though I actually originated using "i[SomeWord]" during my Apple dayz ... yes, iCreatedThisMess
... r u kidding me? no, i am not!
|
|
|
|
|
I was looking at one old SQL stored proc and found this strange behaviour.
DECLARE @Scrap_Qty int
DECLARE @FilledQty int
SET @Scrap_Qty=10
SET @FilledQty = 2
BEGIN
IF @Scrap_Qty > @FilledQty
declare @currDate varchar(10)
Set @currDate= Convert(VARCHAR(10),GetDate(),103)
PRINT @currDate
END
Look at the if condition .. it does not have BEGIN..END... To make thing interesting weather if condition is true or false you will get the output for parameter @currDate
If I add PRINT @Scrap_Qty right after IF and run it again it will only print value for @Scrap_Qty if condition is true. Which leads to question why sql is not complaining about undeclared variable if @Scrap_Qty is less than @FilledQty ?
I would have assumed if condition without BEGIN .. END block will behave like a normal one line to execute if condition is true which in above block is declaration of @currDate variable.
DECLARE @Scrap_Qty int
DECLARE @FilledQty int
SET @Scrap_Qty=10
SET @FilledQty = 2
BEGIN
IF @Scrap_Qty > @FilledQty
PRINT @Scrap_Qty
declare @currDate varchar(10)
Set @currDate= Convert(VARCHAR(10),GetDate(),103)
PRINT @currDate
END
Zen and the art of software maintenance : rm -rf *
Math is like love : a simple idea but it can get complicated.
|
|
|
|
|
declare is not an 'executable' statement.
This means thet the if in your code relates to the set @currdate.... statement only.
Personally, I always use BEGIN...END, even for one liners, but that's a matter of individual preference.
Anyway, thanks for sharing.
Pablo.
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899).
|
|
|
|
|
Pablo Aliskevicius wrote: Personally, I always use BEGIN...END, even for one liners, but
that's a matter of individual preference.
This is exactly the reason for it not to be individual preference. Enhances readability and maintenance. Also, if the original developer used Pablo's notion, they would very likely have encapsulated this right.
|
|
|
|
|
Pablo Aliskevicius wrote: if in your code relates to the set @currdate.... statement only
In that Case if @ScrapQty<@FilledQty it should not Print Date( as i Understood... If i Understood wrong pls clarify ).... But it's Displaying Date  .... Can You Explain That... Pls... Any Explanation will be appreciated....
Thanks....
|
|
|
|
|
The set statement is conditional (first one after the if).
The print statement is another, different statement, and not conditional; it will be executed always.
The point is: always write begin and end.
Best wishes,
Pablo.
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899).
|
|
|
|
|
Pablo Aliskevicius wrote: The set statement is conditional (first one after the if).
I Understood that but even though the cond'n is false... the variable @currDate is assigned to Current date...
That's the thing am unable to understand... Spare my Dumbness.... am trying to learn new things about if.....
|
|
|
|
|
I tried this, expecting the first 'print' would be skipped.
if 1 > 2
declare @a int
print 'print #1'
print 'print #2'
select @a = 3
print @a
go
if 2 > 1
declare @b int
print 'print #3'
print 'print #4'
go
To my surprise, the output was this:
print #1
print #2
3
print #3
print #4
The conclusion? ALWAYS write BEGIN and END. Keep code readable.
Pablo.
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899).
|
|
|
|
|
Pablo Aliskevicius wrote: <layer>To my surprise, the output was this:
print #1
That's the thing am Asking.... am Unable to understand why the Print #1 is Printed....... I am trying to Find why it's printing Print #1 with no Luck......
If we Don't use Begin and End( But i always Use....) Then it will execute the first statement... But Here... That's not the case.... Trying to figure out the Mystery Behind it...
Raj.......
|
|
|
|
|
I'm trying out various command line option parser libraries, and those with verb or command options are few and far between. CLAP[^] is one that handles verbs, e.g. I don't need a separate Console application for each task, where the CLI library just parses the options for that command. I want a library where I can have one Console app, which accepts a command/verb and the options for that verb get parsed. So far I've found only CLAP and ManyConsole[^].
E.g. I don't want to have to have import.exe filename [-repeat] but I want console.exe import filename [-repeat].
So I built a console application called Clap, with this code:
using System;
using CLAP;
namespace Clap
{
class Program
{
static void Main(string[] args)
{
Parser.Run<Program>(args);
}
[Verb(Description = "Imports an Impro CSV report file.", Aliases = "import,imp")]
static void ImportCsv(
[Required]
[Description("Full path to the file to import.")] string filePath)
{
Console.WriteLine("Will import " + filePath);
}
}
}
When I run the application with clap /? or clap import xxx, I get the error message
Unhandled Exception: System.TypeLoadException: Could not load type 'CLAP.Parser' from assembly 'Clap, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
at Clap.Program.Main(String[] args)
Google provided zero leads, so the problem was not well known. Well, how well known is CLAP itself? The Version-=1.0.0.0 gave me the key clue. It looked like the app was trying to load CLAP.Parser from my Clap assembly, not the CLAP library assembly, which is version 4.3.
All it took was to change my assembly name and default namespace to ClapCli and the problem vanished, but just BTW, CLAP is very, very thin. It throws exceptions when verbs arguments are omitted, and expects you to decorate a method to do something with the exception. It also has no built in help provider, and requires you to decorate a method that is called when the user requests help. You must compose and format your own help text for every verb and option.
modified 25-Apr-13 5:32am.
|
|
|
|
|
If you look at one of the examples you'll find this:
using CLAP;
using CLAP.Validation;
class ClapApp
{
.
.
.
}
> "Well, how well known is CLAP itself? "
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
modified 25-Apr-13 5:27am.
|
|
|
|
|
I just changed my app name from 'Clap' to 'ClapCli' and it was fixed. See the last paragraph, that I've just added.
|
|
|
|
|
Your code is like a dose of clap. Errr no, Clap. No, CLAP!
--
Harvey
|
|
|
|
|
How's this one[^]?
It handles verbs as well, and allows you to not use them as well.
Gryphons Are Awesome! Gryphons Are Awesome!
|
|
|
|
|
That ended up my second choice, but ManyConsole won, with better automatic help for available verbs and their options.
|
|
|
|
|
I think you need a virus checker on that...
your code has the clap.
|
|
|
|
|
Not to be pedantic, but I think you'll find the clap is a bacterial infection.
(Just don't ask how I became an expert  )
|
|
|
|
|
No idea why he was "spying" on a client.
We only found this out after he left and we took over the account.
private MailMessage BuildMailMessage(...)
{
...
mailMessage.BCC.Add("guys@address.com");
..
}
.
|
|
|
|
|
Some of us have done that at my job to temporarily monitor production emails to be sure everything is working as expected.
|
|
|
|
|
I can understand why a dev would want to monitor things to ensure that everything is working properly. I also understand why a customer would not like the idea of being spied upon.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Potayto, potawto.
Another thing we do is retain any emails sent from our servers. I suppose that could be considered spying too.
|
|
|
|
|
AspDotNetDev wrote: Some of us have done that at my job to temporarily monitor production emails to
be sure everything is working as expected.
Yeah, that would be my initial reaction too. Just making sure the body/to/ccs/etc are working right. Of course, I'm coming from my world, where we have several automatically-generated emails. Although I would typically write this info to a log instead of copying myself/someone else.
A little disappointing that dev didn't configure the 'emailChecker' address so it could be easily de-configured.
|
|
|
|
|
Somewhere (the daily WTF?) I saw <a href="mailto:....bcc=guys@address.com.."> link. Seems to be not so uncommon.
|
|
|
|
|
Thinking the best, he wanted to be sure that the system was running perfectly, thinking the worst, he may be working for someone else... However, if the account was a corporate account (and not his personal email account), most likely he was monitoring the system.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
