Answered When to use (Return value) and when to use (get; set;)

LupusRex

Member
Joined
Oct 30, 2019
Messages
16
Programming Experience
Beginner
Hi
I've been coding in Autoit for more than a decade, and have just started to use C#.

My Q. is when is it best practice to use return from a method, and when to use get; set from a method?

What I mean with this is:

In Autoit it's best practice to avoid the usage of Global variables to handle data used in methods (Functions), it's better to use Return to return the data to the calling function.
But then Autoit is single threaded and not OOP.

In C# I have the classes and can use the get; set; for variables, is that better than "throw" data between methods?

Example:

In Autoit I would do some thing like this.

C#:
$sData = GetData()

ConsoleWrite($sData) or just ConsoleWrite(GetData())


Func GetData()

$sReadString = FileRead("C:\Test.txt")

Return $sReadString

End Func

In C# I could do the same, but I could also

private string Data { get; Set; }

and the do a Console.WriteLine(Data);

What is best to use in C# Return or get; set;

The reason for my asking is that I have a lot of methods in where I get some data, and then sends it to another method for processing, aso - and finally I return the data to my main method, where I then do the finale handling of the data.
Currently I use the Return statement in 90% of my methods.

Hope that my Question is clear :)

Cheers
/LR
 
A property should return part of what a class object is (object state), and a method what the class can do (computed result).
 
Hi
So if I understand correctly the get; set; is to be used when adding data to the class, and all internal data handling within the class should use return?

Cheers
/LR
 
There's another caveat for properties. C# (and the .NET Framework in general) tries to follow the principle of least surprise. So for properties, there is the expectation by developers that getting or setting properties are relatively cheap. If an operation is going to be expensive, then prefer to use a method instead of a getter/setter. For example, if you had some kind of object representing the "network connection", I would suggest using a property for IsConnected, but using a method for GetAverageLatency().
 
Hi sorry for the late reply, some idiot with a backhoe demolish the city's fiber cable, and left ½ the city without internet and TV, it took fiber company almost a week to get us all online again :mad:

I'm currently porting a License handling that I developed in Autoit, where I from my main program calls the License Handling. When the license handling is called, it first checks it a license for the program exists in the registry, if a license exists it calls a method that pools the license data from the registry, sends that data to a function that parses it into smaller parts (license key, hwid, username etc.), then sends that information to another method that, creates an data string to be used for an online license check, that data is send to yet another method, that sends the data string to the license server, and then sends the servers result to another method that handle that server response, if all checks out, the method returns true and the main function will "shutdown" and allow the program to continue.
If no license exists, I throw a License GUI where the user can enter the license data, and have a method to handle the data entered.

I have something about 12 different methods in my License Handle, whom all "throw" data between them using return.

In C# I have even more methods, corse I've read/heard somewhere, that a method should only do one thing but do that thing well, so I did split some of my Autoit methods up into smaller C# methods.

The way I understand your answers, it's the right way to do it?

Sorry if I sound dumb, but as said this OOP is still quit new for me, and a bit hard to get my head around, due to the way I've been coding the past 15 years.
Cheers
/Rex
 
Not meaning to hijack your topic @LupusRex, but there was a topic on another forum I used to use, and it was on this subject of how-to secure your software with a licence authentication service. I think you should read the content for what I suggested to secure your authentication services. I will bring the main posts into this forum as quoted :
That's a very deep question which can be answered in so many ways and it all depends on how you want to go about distributing those keys and further how you would restrict a given user from using someone elses key. How do you think would be best to do this?

If it where me... I'd probably setup a web server which can take TCP web requests, and have your software issue a once off install key which would be chained to a remote server key upon activation. If the key on user 1s PC is active, and user 2 acquires user 1s CD key/code, then that key would be marked as unauthentic and therefore blocked. The rightful owner/user who bought the key would need to fill in their personal details to acquire a reset code from your website, enabling them to use your software once again. User 1s previous key would be blocked and banned and If user 1s key is stolen more that 2 times, you should ban the user from requesting another key in accordance with your privacy, piracy terms of service; in which they would have to agree too in order to use your services when buying your product. This will cover you legally in most countries.

I hope you find the idea somewhat helpful, and if you were hoping for some starter code, Well I don't think anyone here will be doing that for you for you for free, but if you have something to show for, such as an attempt, or a more specific question, as how-to ascertain the correct way to use TCP clients or how to make web calls to a TCP server from a c# application, then this is likely as much info as you're likely to get on this one. Good luck with the project.
@Skydiver suggested :
If your software is important enough, I recommend buying instead of rolling your own. Lean towards the solutions that require a hardware dongle. (Yes, it sucks for people wanting to run in a VM, but there you have it.)

But if you decide to roll your own, there is some great advise here: Implementing a Partial Serial Number Verification System in Delphi and there is a corresponding C# port.

I can't find the other article, but it had a great discussion of how to have "variable strength" keys as well. And there was another completely different approach using public key encryption. Unfortunately, this one was great in terms of keys and key generation, but had very little advise on how to protect your program from being cracked "e.g. somebody just bypasses your key checks").
While I went on to elaborate :
If you want to roll your own, you'd be best ensuring you bind the keys to a number of factors as pointed out above.

While this is only one layer of the onion, it is also not foolproof, as changing PC/OS/Installing VM's, will also change your MAC address. If your users computer is strong enough to act as a hypervisor, the VMs you run on it will use self-assigned MAC addresses, and these can be managed manually. So when you bind a licence key to a MAC, the MAC address may be subject to change if your user using your key wants to use your application in a virtual environment where changing MAC addresses may be required for them (for whatever reason). Regardless, It wouldn't be something I'd allow.

Consider binding to other sources such as GEO location based on an IP address as well. While some users use VPN's this might be a problem for them too with this method. But by doing this, you will and can determine if a user using one of your provided keys has leaked or lost it, and you can tell when that key has multiple GEO locations. But factor in, that a use may travel a lot, but even so, they will not have a different MAC every time they travel as the MAC is commonly assigned from the network card chipset. So these will be ways of identifying certain boggy keys when you collect a multitude of information(s) from the PC registering the initial serial key.

Further, you could also make 10 digits of your key completely anonymous to both the serial key owner and anyone else who manages to gain access to another users key. The ten digits you keep secret will become a seed in your servers registrar, and thus allows rightful owners of stolen keys to request a reset of the Key they bought. When they reset the key, this does not reset the key they ascertained upon purchase but it generates a new seed key on your server, rendering all users using the same key disabled with an unlicensed version of your application. You could also (as pointed out by Skydiver), add an extra layer of protection for your seed by encrypting the seed on the server and then issue an auth code back to your application for authentication against the seed. If they match, then the new key becomes active again.

You should also factor in personal information which only the key owner would know, as part of registering a key code for use. This will also stop piracy providing the thief of the stolen key does not know the personal details of the user who rightfully owns the key. These methods would also allow you personally or an automated bot script to ban keys that have been used on multiple machines. Lastly, you should put a lot of thought into protecting your code with obfuscation software (which is also not fool proof, but does make it harder) as well as other checks to ensure your key checks are not being avoided as pointed out by Skydiver.
And the important part :
Note :: When they reset the key, this does not reset the key they ascertained upon purchase but it generates a new seed key on your server, rendering all users using the same key disabled with an unlicensed version of your application.

If you decide to implement this idea, which I think you should. When you begin binding the personal data to the purchased key, it should be bind to the seed of the key and not the actual key itself. The key supplied to the user at purchase is only "like" an activator for them to bind to a ten digit seed, and the binding data will require them to register the auth code they received from your server upon activation of the purchased key code. Thus this make sense, have i explained this well enough or have I over complicated with this elaboration?

Curious if anyone else has any suggestions to make this concept better, or if there is a better way to go about it? Post your thoughts.

PS, you should still bind to the MAC address and any other data also. There is no reason for you not to, especially if your keys protection is priority.
To summarise, on these quotes, you really shouldn't be storing the Keys on a Users PC. This is really bad practice and this is how armature devs used to do it back in the days when Winforms was still a thing. As time has passed, us devs are smarter, and have more common sense than to follow the mistakes of those before us who used to follow this exact concept you're rolling out. Which is a bad one. Your concept will result in many of your keys being leaked on the blackmarket and the dark web for all to use. The ideas I've set forth above will help you to secure your application software in a more practical and protective manner.

Regarding your post here and your question. Using a property can be handy if you want to delegate events to your property. In a setter you have the option to add checks to ensure a value is within a specific range. In terms of when you should return a value, really depends on whether or not you want to acquire a property value from a class but continue executing your code in the current method that called your return type function to acquire the value of that function for use in your current method. I mean, we could go on and on about this one with for instance examples, but it really comes down to logic at the end of the day, and what you aim to achieve, and how you want to achieve how your executing code runs.

Hope you found this helpful.
 
Last edited:
Hi Sheepings
I think that I already have read that article, or one like that.

you really shouldn't be storing the Keys on a Users PC. This is really bad practice and this is how armature devs used to do it back in the days when Winforms was still a thing. As time has passed, us devs are smarter, and have more common sense than to follow the mistakes of those before us who used to follow this exact concept you're rolling out. Which is a bad one. Your concept will result in many of your keys being leaked on the blackmarket and the dark web for all to use. The ideas I've set forth above will help you to secure your application software in a more practical and protective manner.
The main reason for me to store the license data locally, is to allow the user to work offline (for a short time) - though each time my program starts it does check for internet connection, and if found it does an online check to my server.
I allow for up to 3. failed online checks, after that the program stops working until it have had a connection to my license server. Also I use an unique HardWareIDKey which is stored on my server, if the user should had "sold" the license key - it will be blocked after 3 HWID changes, and after that it require a manually reactivation from an Admin.
My local license data, is also locked to the pc using the HWID, and saved in non plain text.

Cheers
/Rex
 
The main reason for me to store the license data locally, is to allow the user to work offline
You clearly didn't read the article I wrote. If you did, you would clearly see that your approach is all wrong. There is no reason at all for you to store your keys on the users computer. You should provide a GUID like key which is tied to the actual license key on your servers. It's the GUID you give to your user to activate and that binds to the License key. No user should ever see the real license key. This way you can ban a key and all associated GUIDS from your server, and if the GUID is used by any other user (as explained above), then that GUID will also be banned by every user bound to that key. Keys and GUIDS are not the same thing. But if you can't be bothered to read the article properly, I'm not going to bother explaining it further.

It's your software at the end of the day, and if your APP goes viral, it won't be long before you begin to run out of keys. In which case, think ahead so that your license software comes with an updater. You'll need it... What do I know; I'm only speaking from experience...
 
I meant no offends, and as I wrote I might have read the post, or some thing similar, though I did read what you quoted.
If you could post a link to the article, I would like to read all of it.
But as stated in the main post, I'm (trying to) port a code from Autoit to C#, the license handle I have - is one I wrote years ago, and to be hones I thought I was very clever about the way I created it :D, when thinking that the first license handle I created was only a txt file containing all the issued license keys, which then was placed on my server - and the program just looked in the file to see if the license existed.

I'm not saying that my way is correct, I only telling why I did it the way I did it.

The main reason why I did allow the users to work off line was that the server I use to host my license server, some times goes offline not often but it have happen - so to be sure that the programs continues to work, until either the server is up again, or I get my domain moved to another server, the programs need to function corse those that use them, can't get there work done without them.

I'm far from an experienced developer, I'm self thought and I lean new things every day, and is always happy when some with greater experience, shares there knowledge with me so I might become an better coder/programmer. (no sas, I mean that genuine, I love to learn from those who know how to do it, thats how I learned to weld tig, lay brigs and a lot of other craftsman stuff.)

Non of what it wrote is meant in a negative way, and I'm hoping that it wont be read as such. English isn't my native language and some times, what I mean gets screwed in translation :(

Cheers
/Rex
 
Ahh oki :)
Thx for the link, I will go thru the post when I have some spare time.

Cheers
/Rex
 
Back
Top Bottom