Tag Info

Hot answers tagged

25

They are named differently because semantically they are quite different: A collection's Count is the number of items currently stored in it and can potentially change over time. An array's Length is the maximum number of items it can hold (it will have a length of 10 even if you haven't stored that many items in it) and is immutable. Example: If I have ...


23

It smells like you should limit the number of states your Room class can be in. The very fact that you're asking about what to do when Client is null is a hint that Room's state space is too large. To keep things simple I wouldn't allow the Client property of any Room instance to ever be null. That means the code within Room can safely assume the Client ...


21

Just a few considerations: a) Why is there a getter specifically for the ClientId when there's already a public getter for the Client instance itself? I don't see why the information that the ClientId is a long has to be carved in stone in the signature of Room. b) Regarding the second opinion you could introduce a constant Invalid_Client_Id. c) Regarding ...


17

I disagree with all three of the opinions. If Client can never be null, then don't even make it possible for it to be null! Set the value of Client in the constructor Throw an ArgumentNullException in the constructor. So your code would be something like: public class Room { private Client theClient; public Room(Client client) { ...


7

The problem is that you've effectively created a global variable for accessing these objects, the Foolist class. This has drawbacks for things like testability and is in general just poor design. Global state doesn't help make code easy to read and the consuming classes can never be isolated from the Foos (look up mocking) d when testing. Avoid the static ...


6

As long as all your configuration options come from a file, using interfaces does not bring you any benefit, since your configuration file can only provide fixed values. Even if you have to deal with more than one option per service, I do not see any convincing reason for using interfaces. You can still utilize simple "data objects" for the configuration ...


6

From C#/.NET Little Wonders: Expression-Bodied Members in C# 6: So, should you use this? It all comes down to style. My gut would be to limit this to simple expressions and statements that can clearly be understood at first glance. (emphasis, mine; see Update 1 below) More from the Summary of the article above: So C# 6 now gives us the ability ...


5

The second and third options should be avoided - the getter should not smack the caller with an exception they have no control over. You should decide whether Client can ever be null. If so, you should provide a way for a caller to check whether it is null before accessing it (e.g., bool ClientIsNull property). If you decide that Client can never be null, ...


4

Fundamentally, there's no problem described in the question that actually needs a solution. You've given no reason for a Foo holder to exist, or what it should be able to do. So really, FooList is completely useless. If you need a Foo, there's a language feature for that- new Foo(1). There's no reason for any additional holding to be baked in to the Foo ...


3

If you were talking about manual refactoring to bring your code up to "C# 6.0 standard", I would heavily vote against refactoring parts of your code in areas you are not currently working with. That would bring only a minimal benefit for a certain risk of breaking things unintentionally. However, you are talking about an automated migration. In such a ...


3

No. And even if the performance would be different (which it is not, see the link in the comment given by Sami), what do you think is more important, speed or correctness? A program which does not work correctly is pretty useless, how fast it may ever be. The only reason I can think of is that you are 100% sure the "logic" part does not throw any ...


3

Functional programming languages consist only of expressions, so most have had a feature like this from essentially the beginning. You use it when you have a relatively short, often frequently repeated, expression that can be replaced by an even shorter, much more meaningful name. A common example would be predicates that are used elsewhere, like: public ...


2

The benefit of immutability is that it doesn't matter as much what you do with your references to it. Globals, static classes, and singletons are much less problematic than their mutable counterparts, because you don't have to synchronize mutations and track the order dependencies that creates. However, they still have the issues with mocking out for unit ...


2

If I could tell everyone who tackles the problem of injecting values from configs into a DI paradigm one thing, it would be this: You don't have to put all config access through one monolithic dependency. Just because your settings all come from one place under the hood doesn't mean they all belong together, and that you have to persist the config as one ...


2

So you have a 5 neatly separated components, which I suppose you can reuse later with different code. Yet you thinking of having a single interface shared between those components, which will provide a bunch of irrelevant config properties, e.g. we can assume that 80% of properties will not be relevant for each of the component. Doesn't seem logical to ...


2

If a null Client property is a supported state, consider using a NullObject. But most likely this is an exceptional state, so you should make it impossible (or just not very convenient) to end up with a null Client: public Client Client { get; private set; } public Room(Client client) { Client = client; } public void SetClient(Client client) { ...


2

If it was me, I'd do something similar to the following, utilising split() and switch: public void ProcessInput(string lineOfInput) { string[] parts = lineOfInput.Split(' '); switch (parts[0]) { case "/j": case "/join": JoinChannel(parts[1]); break; case "/w": case "/whisper": ...


1

It depends. Not all c# 6 features/uses are available in lower .NET versions (see http://stackoverflow.com/questions/28921701/does-c-sharp-6-0-work-for-net-4-0). If your consumers can't move to the latest and greatest libraries, don't update. Does your team know the new features? If not, you should maybe do some sort of training before dumping everything in ...


1

It depends. Using a reader/writer lock rather than a critical section can be beneficial if read operations are noticeably more common than write operations. But I think you could probably achieve more by changing your application architecture. If writes are rare, you can probably get much better performance by treating the collection as immutable and ...


1

As of c# 6.0, which is now released, you should just do this, public class Room { public Room(Client client) { this.Client = client; } public Client Client { get; } } public class Client { public Client(long id) { this.Id = id; } public long Id { get; } } Raising a property of Client to Room is an obvious ...


1

I would vote in favor #1, because I find it slightly easier to understand what's going on and control the behavior. We used this approach to build a fairly large enterprisey apps without too much fuss. It also is easily customizable, if needed (e.g. would 1 token per user suffice? Would you need multiple token if user simultaneously logs in from multiple ...



Only top voted, non community-wiki answers of a minimum length are eligible