It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
My reasons for the idea/proposal are following:
1) Console.WriteXX() is possibly used more often than many keywords in C#
2) The Console as an I/O device is not going away anytime soon.
3) I cannot think of any general purpose programming language which doesn't provide the "write to console" facility in one form or another.
4) aesthetics (i.e. clean, simple, short , direct )
5) print "Hello" ; doesn't make me think that I am typing more than whats needed. Every time I have to write Console.WritXX() ... or even read it in code , its a chore.
6) Its closer to the C/C++ family values and tradition of providing special status to the basic text based I/O
7) Its hard to conceive of a future scenario when the decision to make "print" a keyword will be regretted.
8) print as in { print "hello"; } instead of print as in { print("hello");} is unlikely to break any existing code.
Because C# isn't only is generally not used in a console. Wether it's ASP.NET, WinForms or WPF, there are many uses for the langage where "printing" does not make any sense.
In C# we have a lot of ways to output the data. It's very confusing if you change Console.Write to print, because programmers may ask "print to what? to the screen? to the printer?". While using Console.Write is quite clear, we know it's writing data to the Console. And also FileStream.Write make us know that it's writing to a file. A MemoryStream.Write is writing to the memory... It's so nice, isn't it? So why do we need a confusing print?
Why not create an alias for System.out.WriteLine() to save your wrist?
using c = System.Console;
c.WriteLine("Hello World");
Or use a code snippet in your IDE?
Console.WriteLine is a .NET Framework method, so all .NET languages use it consistently. Why add additional keywords to c# which is only one of many .NET languages?
Print is too generic to describe what is really going on, and it only really applies to the console itself. There are several different methods for outputting information to various interfaces, and WriteXX (as you put it) is more descriptive of what is actually occurring. You're not printing anything, you're writing it to the interface. C# was made to be more descriptive of what is going on, not to latch onto holdovers of other languages.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I have inherited a c# (wpf) project where part of the code is a user friendly UI (list boxes, radio buttons,sliders, etc.) for a non SQL person that creates a SQL query statement ... then queries a DB and returns the results.
The code to create the SQL basically walks thru the UI components and concatenates a string.
I'm slowing finding either bugs in the code and\or misinterpretations of the what was needed.
I want to update the code to a more elegant and maintainable state. Are there any:
'design patterns' for this?
best practices?
examples of good code?
Thanks
Many wrote code like that when .net started; there are indeed many design patterns to move on from this.
Firstly, the project mixes c# and sql syntax. Separate those to halve the code size and double the elegance. Also to remove sql injection possibilities.
identify what the final sql typically looks like. Might be
select a,b,c from d join e join f where x and y and z
write a stored procedure on the sql side to encapsulate this, passing parameters x, y , z
change the c# code to call the stored procedure instead of the sql statement
c# debugging can now involve just viewing the parameters you end up with when you get to call the sql statement
on the sql side, the next step is to move the table joins and any static where clauses into a view, which will further simplify the stored procedure and also give the sql server more opportunity to pre-optimise the data selection.
Good luck
I don't have any particular design-patterns for this, but if I was to implement something of this kind, I think I would try to create a sort of abstract representation of each SQL-operation that I would need to work with; perhaps something like the way SQLite documents it's queries.
Thinking in this way may be helpful when creating data structures to represent your queries.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have a field that's stored in the database as a string. It's actually a comma-separated string of numbers that I convert to a list of longs. The lines of code that do the conversion look somewhat like this:
TheListOfLongs = (from string s in StringFromDB.Split(',')
select Convert.ToInt64(s)).ToList<long>();
The code that creates the database storage string looks like this:
return String.Join(",", TheListOfLongs.Select(x=> x.ToString()).ToArray());
This works fine but as you can see, if for some reason there's a problem with the string, the code in the first line of code breaks on Convert.ToInt64(s).
Now I know I can wrap all this around a try statement but my question is this: can storing and retrieving a string in the database corrupt the string (in which case I definitely need the try statement) or is this a one a trillion odd type of event?
I wouldn't worry about corrupt data per se. However, you definitely need to handle the more general case where you can't parse what should be numeric data.
Even in the most controlled situations it is good programming practice to provide conditions for when you can't process data as you're expecting to be able to. What that means to your application is something you'll need to decide. Wrapping the statement with a try..catch will prevent your application from choking, but may not be appropriate if the parsed list is critical later on.
Selecting from the DB shouldn't corrupt your string.
If the connection is dropped mid transfer or something like that then an exception is thrown.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
This is generic question and it's interesting what approach do you use guys and what are pros and cons? Sometimes methods return lists (for example, NSMutableArray or NSArray in obj-c) and my current approach is to return nil if there's nothing to return. It makes sense to return nil if it's just object of some native or custom class, however should we return alloc'ed/init'ed empty array if nothing was found?
The question is primarily targeted for objective-c but is also related to other languages. Objective-c has nice feature to call methods on nil, however this is not the case for all other languages. So it's also interesting to hear arguments from other devs (java, c# and PHP devs).
UPDATE It's strange why some are voting on closing the question. Design pattern related questions also could be described as personal opinion questions, however architecture & code quality questions are more important thing than just syntax questions.
There is not a single answer I believe.
For myself I decided to return the result of expected type if possible and NULL otherwise.
Say, in my homebrewed DAL the getAll method returns an empty array (list) - so it can be passed to PHP's foreach operator without raising an error.
On the other hand, the getRow method, which is supposed to return an associative array, returns NULL in case of none data found, as empty array would be as equally useless.
Returning a null and an empty container have two different meanings in my opinion. An empty container would mean, no result matched your query but it was successful, while a null result would mean something went wrong.
In the first case if you have written code somewhere to say:
print "You have found" + GetResults.Size() + " results"
You will be able to print that zero results matched the query. While if you decide on using null, you will have to add explicit checks.
I have also had some troubles with serializing result to JSON as a response to a web server request, later on I regretted that I chose to return null instead of empty array.
Return nil or whatever is clearly a non-thing. Don't do more work than needs to be done.
Returning an empty array may cause many useless pointers and structures to be allocated, when all you really need is to say, "I have nothing for you."
In Cocoa,
If you return a nil to some array you need to check afterwards, that you are not trying to access the array Index.
And it is good to return nil instead of an array without any object.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
How would you name an interface which provides 1 method inUse()?
I would actually reconsider the name 'inUse()' in the first place; A boolean value obviously has only two possible values, but you're actually adding the ability to get a state. I'd consider declaring an enum
public enum UsageState
{
Idle,
InUse
}
and name your interface IHasUsageState. This gives you the flexibility of adding things like Starting, Finishing, WaitingToBeUsed or other options depending on precisely what is is you're doing, for example if you have threading issues to deal with in the future.
Also, you eliminate the need for negative checks like if (!obj.InUse()) { } in favor of the more readable and intuitive if (obj.Usage == UsageState.Idle) { }, not to mention you may decide in the future that you might want it to specify WHY it's idle.
IUsageIndicator if you want to show that your object is currently in use or not.
IUsable if you want to show that your object can be used or not.
I would name it. IInUse. Looks good...
I would prefer to name it as IUsable keeping in mind the standard conventions that MS follows. (Eg: IEnumerable, IComparable etc)
I would prefer
InUsable. Sounds everlasting.
see here
I would name it. IUsable. Looks good...
This is what I would have done in Java
public interface Usable {
public boolean inUse();
}
It should start with Uppercase 'I', so the interface name becomes in your case IInUse.
Follow the C# coding standards over here.
How about IExclusiveUseObject?
are you looking for answers for both c# and java?
As a c-sharper, I prefix with "I" and most c# developers I talk to do also, probably because it's in the microsoft naming conventions.
However interestingly when search around for java naming conventions I see a mix of prefixed and no prefix.
So in c# perhaps something like:
public interface IUsable {
void InUse();
}
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I'm just asking this, because the same happened to me when trying to iterate over a DataRowCollection:
DataSet s;
...
foreach (var x in s.Tables[0].Rows)
{
//IntelliSense doesn't work here. It takes 'x' as an object.
}
I saw #Marc Gravell answer in Why is there no Intellisense with 'var' variables in 'foreach' statements in C#?, and now it's clear to me why this is happening.
I decided to take a look at the code of the DataRowCollection class, and GetEnumerator() is:
return this.list.GetEnumerator();
where list is a DataRowTree type that inherits the abstract class RBTree<K> (by the way, never knew there was an implementation of a Red-Black Tree in .NET before) which implements IEnumerable instead of IEnumerable<K>.
Is too hard to make RBTree<K> implement IEnumerable<K>? That would solve the main problem here.
I suppose it was developed like this in previous versions of .NET, but that doesn't really make sense anymore, does it?
My question is:
Is .NET old code updated in new releases? (for example, make DataRowCollection implement IEnumerable<DataRow> instead of IEnumerable)
Breaking changes, such as changing the class hierachy, is only implemented if there's a really good reason. In this case it's only for convinience.
An example of why it's a breaking change:
Let's say a project has these two methods.
public void Foo(object obj){
Console.WriteLine(obj.ToString();
}
public void Foo<T>(IEnumerable<T> obj){
throw new Exception();
}
now the change you want will make a program that has been recompiled but not changed throw an exception every time instead of printing to the console. It's not that it throws that's the problem but that the behaviour is different.
There's other ways such a change could break/alter a perfectly good program so the benefits (being able to write var in foreach loops) does not outweigh the cost (designing, implementing,testing,documenting), nor the potential costs of breaking customers work.