Tag Info

Hot answers tagged

128

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


38

They already have a term for that in the Javascript world. They are called Immediately Invoked Function Expressions (IIFE). What it is IIFE functions are not given a name. Instead, they are executed once as the interpreter comes across them: var area = function() { var width = 3; var height = 2; return width * height; }(); The final ...


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


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)


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


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


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


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


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


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


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

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



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