The Weird and The Wonderful
The Weird and The Wonderful forum is a place to post Coding Horrors,
Worst Practices, and the occasional flash of brilliance.
We all come across code that simply boggles the mind. Lazy kludges, embarrasing mistakes, horrid
workarounds and developers just not quite getting it. And then somedays we come across - or write -
the truly sublime.
Post your Best, your worst, and your most interesting. But please - no
programming questions . This forum is purely for amusement and discussions on code snippets. All
actual programming questions will be removed.
|
|
 |

|
try
{
account.Save();
}
catch { ; }
|
|
|
|

|
I notice that a fair few of the recent posts here seem out of place.
Can't people read?
ps. I guess that by posting this, I now have to include myself in that category, but I'm hoping to be indulged.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|

|
Apologies if this subject has already been discussed before.
After stumbling upon last September's Best C# Article NET-CLR-Injection-Modify-IL-Code-during-Run-time and learning about endless security issues with the Java Runtime.
Are these platforms actually safer than conventional compiled executables?
Isn't the whole point of Data Execution Prevention (DEP) meant to stop run-time modification of running code? The CLR/JAVA Runtime engines have the only *native* code that DEP has any direct control of, but they are allowed to run without question, because of some dubious assumption that code for a virtual cpu/machine can do no real damage.
Maybe I'm wrong, but I can't help thinking that code under direct control of the 'real' cpu is safer than these virtualized runtime environments.
I'm not fully versed in .NET or Java coding. Anyone care to shed more light on the subject.
modified 9 May '13 - 20:02.
|
|
|
|

|
I think the life of software developer is a nothing but "The journey between LOGIN & LOGOUT"
What is your opinion??
eNJOY c0ding....
|
|
|
|

|
I am sure this was one of the hello-world codes for many of us ... But I wonder why the letter "i" .. I mean why on earth? With "a" the leading character why "i" ...
After sometime I found out that Fortran language (which was/is historically used for scientific calculations) use "i" as a starting character for all integer type variables, and the quickest varible to write would be "i"
Most authors and coders continued to use "i" even in C and then to C++ and then to C#, Java etc ...
Is this an interpretation?
|
|
|
|

|
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.
|
|
|
|

|
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:32.
|
|
|
|

|
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");
..
}
.
|
|
|
|
|

|
Link to the article
For More detail explanation(PDF)
Counting arrays from 0 simplifies the computation of the memory address of each element.
If an array is stored at a given position in memory (it’s called the address) the position of each element can be computed as
element(n) = address + n * size_of_the_element
element(n) = address + (n-1) * size_of_the_element
modified 22 Apr '13 - 13:45.
|
|
|
|
 |
|
|
General
News
Suggestion
Question
Bug
Answer
Joke
Rant
Admin