Tag Info

New answers tagged

2

Global state, including extern variables and non-const static variables in file scope or in functions can frequently be an easy solution to a given problem, but there are three issues: static makes code untestable, because static variables tend to be non-replaceable dependencies. Or in more OOP-y words: you aren't following the Dependency Inversion ...


5

In a well-design C program, a file-static variable is similar to a private static member of a class: It can only be accessed by functions in that file, similar to how a private static member variable can only be accessed by functions in the class in which it is defined. There is only one copy of the variable. Its lifetime is the program lifetime. An ...


0

I do not consider variables with file-scope as bad as global variables. After all, all accesses to these variables are confined to one single source file. With that restriction, file-scope variables are pretty much as good or bad as a C++ private static data member, and you don't forbid their use, do you?


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


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


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


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


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


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


0

I'm currently working on a big project with 6 developers. We have a lot of models and I noticed that if you have like 5 or 6 scopes things start to look cluttered. If we are using the self. syntax things look a lot cleaner then a lambda. So I guess 2 things: - looks cleaner - consistency (like you said) Note that this post is solely based on personal ...


4

In this particular case, @Mattieu M. has the right solution. In the more general case, where there is no similar transform, you have to ask yourself: Is there any chance a future programmer might mess this up? The answer is usually yes. Which means, yes, you should add the call. Maybe some future version of the framework starts with all views OFF ...


129

You have an invariant: Only a single view (out of 3) is ever active (and visible). Then, I suggest that you provide a function to switch the activity and visibility of ALL views at once: [setActiveView viewID:2] This function will: check if the view is already active, avoiding unnecessary work set the view as active, and visible set the other 2 ...


11

Alternate idea: if your goal is to prevent bugs occurring because people forget there's three views and do something with only two of them that they really should do with all of them, then make a function that makes it impossible to forget: setViewVisibilities(0.0f, 0.0f, 1.0f) Now you have something far more powerful - compile time guarantees you haven't ...


8

I would believe that adding a comment explaining that the call is unneeded (and why) is best. (perhaps, the fact that a call is unneeded, or that you need a comment about that, might be a code smell)


0

Should I provide these methods or should I let people implement their own? I'm trying to find the post (I think it was Stephen Cleary on SO), but one of the answers had made the point that he preferred to make his operations synchronous and let the client decide if they want to call them asynchronously or not. It stuck with me because it was Stephen ...


6

The code form you want is called A-normal form (ANF); it is not always more readable, but it might be more easily tranformable inside compilers, and is useful for precise garbage collection (hence, many compilers are transforming the source code into some intermediate ANF). See also SSA form. I don't believe that ANF is always more readable; on the ...


-3

I'm building an app in C# that needs a fixed-length id, which is a string representation of a hex number. So use a string. Anything else is a waste of time. On the day you find that you somehow passed an ID code string of the wrong length, add an extension method to check the string length.


1

Your code is much too complicated for such a simple requirement. This is because you are focusing on the representation (four hex characters) when you should be focusing on the thing represented, which is merely a two-byte integer. A C# ushort is precisely that type. For convenience, you could create a struct (not a class) that contains a short and methods ...


1

The second approach seems more clean, however if I need a new length for the ids I would have to make a new class AND replace the instance of the old class everywhere it is used You already gave the two striking arguments why this is exact the opposite of beeing clean. So you should avoid specific derivations for specific lengths. However, you wrote ...



Top 50 recent answers are included