|
You specified it when you wrote System.Text.StringBuilder ...
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
Ah, so perhaps you were agreeing with me. I see now that my statement was unclear and I have added clarification.
|
|
|
|
|
Yes yes, I really have bad time expressing this things on languages other than my own...
(actually, even in my own language sometimes I've bad times trying to express my self... )
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
There I mentioned StringBuilder is just an example. I found many similar things like below.
System.Diagnostics.Trace.Write
System.Diagnostics.Trace.WriteLine
System.Drawing.Color
System.Configuration.Configuration
System.IO.StreamWriter
System.IO.StreamReader
System.IO.FileInfo
System.IO.FileStream
System.IO.StringReader
System.IO.StringWriter
System.IO.TextReader
System.IO.TextWriter
System.Xml.XmlDocument
etc.,
....
...
..
. Why so much repetitions? After that some more 100s of replacements done. Namespace at top.
thatrajaNobody remains a virgin, Life screws everyone
|
|
|
|
|
Not that it's a good excuse, but it makes copy/pasting the code easier
If you'd import the System.Text Namespace and copy/pasted the entire thing to another file you'd get an error for every StringBuilder .
StringBuilder is a common class that should be known to all programmers, but for some of the more 'obscure' classes I prefer to use the entire namespace.
Something like: SomeCompany.ThirdPartyTool.Library.PartINeed.SubPart.TheActualClass .
At least now everyone who reads the code knows where this TheActualClass comes from, even if they didn't know the third party component.
What I find even more annoying than having System.Text.StringBuilder 100+ times in your code is having lots of imports/using statements at the top of every code file. Especially when half of them aren't used. In C# you can right-click and remove unused imports. VB (unfortunately) doesn't have this option (and please save me the C# vs. VB discussion).
I wouldn't call this a code horror, but in this case an import of System.Text does seem logical.
The real horror might be that you use 100+ StringBuilders instead of re-use one... But I'll leave that to you
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
"VB (unfortunately) doesn't have this option (and please save me the C# vs. VB discussion)."
It does have that option, at least in the version I've used (VB2010)
|
|
|
|
|
Really? I was never able to find it. Just right click and...?
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
Here is a situation: we have few customer who take international calling service from us. well, for all the customer there is a common rate table. but there is other 10 + customer who has their won rate table, they got cheaper service. so the genius engineer developed that code in VBA: the code is something like below:
SELECT * FROM commontimetable WHERE CustomerId <> 'Customer one' AND CustomerId <> 'Customer tow' AND .... CustomerId <> 'Customer ***'
and then for all the customer with own time table get their own query
and when a new customer get added with different rate table I had to add another AND + condition
I wish I was smart like him
|
|
|
|
|
I totally agree but I've worked in environments where that is the best option.
1. KPI is based on the number of tasks completed. In which case this would have been the quickest resolution.
2. Only implement the requirements. Nothing more. Nothing less.
It's sad but true that in some environments, adding a flag to the database schema and a check box to the UI, can lead to problems. Unless that was specifically requested.
"You get that on the big jobs."
|
|
|
|
|
Isn't there a table, where you can get all the Customest with own timetable from? Then you could use a sub-select instead of coding it hard.
When not: bad database-draft, when yes: bad select-query.
------------------------------
Author of Primary ROleplaying SysTem
How do I take my coffee? Black as midnight on a moonless night.
War doesn't determine who's right. War determines who's left.
|
|
|
|
|
That's what I did, I updated the system. Where each user has a timetable name. if there is different then I put the different table name, I put this on customer basic info table.
|
|
|
|
|
------------------------------
Author of Primary ROleplaying SysTem
How do I take my coffee? Black as midnight on a moonless night.
War doesn't determine who's right. War determines who's left.
|
|
|
|
|
I am/we are moving from our 6 years old home grown entity framework towards .NET 4.0 Entity Framework and LINQ to Entities - I like it!
At a first glance it looked like I had to manually code LINQ queries into every Business-Object, even for standard operations (CRUD).
Let me show you a tiny generic BusinessObject, that fits perfectly into ObjectDataSource:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.ComponentModel;
using System.Data.Objects.DataClasses;
using System.Data.Objects;
using System.Data;
using System.Reflection;
namespace DataObjectDemo {
[DataObject]
public abstract class BasicWebBO<TEntity, TKey, TContext>
where TEntity : EntityObject,new()
where TContext : ObjectContext, new() {
private TContext _context;
protected TContext Context {
get {if (_context == null) {
_context = new TContext();
}
return _context;
}
}
protected virtual string EntitySetName {
get {
return typeof(TEntity).Name;
}
}
[DataObjectMethod(DataObjectMethodType.Insert)]
public virtual void Insert(TEntity entity) {
Context.AddObject(typeof(TEntity).Name,entity);
Context.SaveChanges();
}
[DataObjectMethod(DataObjectMethodType.Update)]
public virtual void Update(TEntity entity) {
Context.AttachTo(EntitySetName, entity);
Context.ObjectStateManager.
ChangeObjectState(
entity, System.Data.EntityState.Modified);
Context.ApplyCurrentValues(
entity.EntityKey.EntitySetName, entity);
Context.SaveChanges();
}
[DataObjectMethod(DataObjectMethodType.Delete)]
public virtual void Delete(TEntity entity) {
Context.AttachTo(EntitySetName, entity);
Context.DeleteObject(entity);
Context.SaveChanges();
}
[DataObjectMethod(DataObjectMethodType.Select)]
public virtual TEntity Select(TKey key) {
TEntity template = new TEntity();
PropertyInfo pi = typeof(TEntity).GetProperties()[0];
pi.SetValue(template, key, null);
EntityKey entityKey =
Context.CreateEntityKey(EntitySetName, template);
object entity;
if (Context.TryGetObjectByKey(entityKey, out entity)) {
return entity as TEntity;
}
return null;
}
Now you can easily derive a BusinessObject, eg. PersonBO:
public class PersonBO : BasicWebBO<Person, int, DemoEntities> {
}
PersonBO is now ready to use and provides a standard type-save implementation for ObjectDataSource-CRUD-Methods along with designer support
You can also extend PersonBO with any additional business logic and Custom-CRUD-Methods
[DataObjectMethod(DataObjectMethodType.Select)]
public IEnumerable<Person> SelectAll() {
return from person in Context.Person select person;
}
[DataObjectMethod(DataObjectMethodType.Update)]
public void UpdateImage(int PNR, byte[] image) {
}
You may have noticed the hack around the primary key value. It would also make sense, to declare this method abstract.
wish you well
modified 1-Jul-12 20:14pm.
|
|
|
|
|
Hi,
Woppelmann P wrote: Now you can easily derive a BusinessObject
This idea of deriving business object is fantastic.
You should use this idea as a new article. The user's will come to know about this. This is not the right place of this kind of ideas. You can refer Here[^] for articles and tips.
Warm Regards.
--Amit
|
|
|
|
|
Try
Dim objReader As New System.IO.StreamReader(Application.StartupPath & "\" & TextBox3.Text & "_OAuthtk.dat")
My.Settings.m_strToken = objReader.ReadLine()
My.Settings.Save()
objReader.Close()
Dim objReader1 As New System.IO.StreamReader(Application.StartupPath & "\" & TextBox3.Text & "_OAuthtkST.dat")
My.Settings.m_strTokenSecret = objReader1.ReadLine()
My.Settings.Save()
objReader1.Close()
Me.Hide()
Form1.Show()
Catch ex As Exception
Me.Hide()
Form3.Show()
End Try
I used that code in my application called TRocket to check if the files are present or not :P *The lazy way to check/read.
|
|
|
|
|
You call it lazy I call it simple.
You could check for the file existence
if (File.Exist(...)) {...}
But what if the file exist but is not readable?
I think your code is fine.
I also often hear you should not catch all.
In some other languages, the compiler know what exception is raised by a block of code. Catching the required exception in that scenario is easy.
In C#, it is harder. If you catch the exceptions you can guess, you might miss the rare exceptions like disk disconnected, out of memory or god knows.
I am not a programmer that put program elegance or programmer state of mind before the end-user satisfaction.
I think catching all is safer.
In one word, I think your code if FINE.
modified 8-Jun-12 18:19pm.
|
|
|
|
|
+5
Bastard Programmer from Hell
|
|
|
|
|
On the other hand, checking whether or not a file exists and is readable before you need to access it may not be worth the trouble because it may not exist or be readable later when you do need to access it. Generally, I prefer to just access it when I need to and deal problems then.
|
|
|
|
|
Perhaps I was not clear.
You summarized my exact thoughts
|
|
|
|
|
I have this project which is so nasty I don't even want to touch it but as a jock on my professional life I inherited it from a master developers. Application is so pathatically written it makes my mind go crazy whenever there is a fix required. So here is one example of hundreds of stord proc it uses or not uses ( some stord proc are just there for fun ).
CREATE PROCEDURE [dbo].[uspInsertUpdateDeleteFltcode]
@fltCode varchar(8),@fltDesc Varchar(20),@fltGrp varchar(8),@casterRelated bit,
@fltType varchar(2),@flag char(1),@shortDesc Varchar(8),@rptOrd Numeric(9,0)
AS
declare @Operation char(1)
BEGIN
SET NOCOUNT ON;
SET @operation=@flag
IF @operation='I'
BEGIN
INSERT INTO FltCode (Flt_Code,Flt_Desc,Flt_Grp,Caster_Related,Flt_Type,Sh_Desc,Rpt_Ord)
VALUES(@fltCode,@fltDesc,@fltGrp,@casterRelated,@fltType,@shortDesc,@rptOrd)
END
IF @operation='U'
BEGIN
....
...
..
Some of them call some other stord procs internally. Some are at least 500 lines long and loop within loop within loop and so on but this is insane why in the world you have one strod proc that do every CURD operation ? Why ..
Zen and the art of software maintenance : rm -rf *
Math is like love : a simple idea but it can get complicated.
|
|
|
|
|
virang_21 wrote: jock on my professional
So you think you're some jock[^]. I believe it's more like a joke.
virang_21 wrote: pathatically
Your spelling is quite pathetic.
virang_21 wrote: other stord procs internally
So how does a town in Norway[^] figure into all this?
virang_21 wrote: have one strod
An what's this bit with that Russian civil war hero[^]?
virang_21 wrote: every CURD[^] operation
Hmmm,makes me think of cheese. I wonder why?
I'm trying to figure out real hard what really belongs into the hall of shame here.
Cheers!
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
|
|
|
|
|
yea mate ... after long debug spelling doesn't matter much.. and English ( Engrish ) is not my first language.. I still swear in my mother tongue when I am frustrated...
Zen and the art of software maintenance : rm -rf *
Math is like love : a simple idea but it can get complicated.
|
|
|
|
|
This post made me laugh.
It's not his native language neither mine for that matter.
No shame there, the guy is frustrated.
|
|
|
|
|
virang_21 wrote: Some are at least 500 lines long and loop within loop within loop and so on but this is insane why in the world you have one strod proc that do every CURD operation ? Why .
For fun, I do not see any other 'advantages'.
Nice prefixes - must have been written by a VB6-programmer
Bastard Programmer from Hell
|
|
|
|
|
Eddy Vluggen wrote: must have been written by a VB6-programmer
This joke is less and less funny when you know, work with, and refactor code by vb6 programmers
If it moves, compile it
|
|
|
|