Naming stuff...
-
Member 9167057 wrote:
I won't get a foreigner to work on my team because my company doesn't grasp for foreigners because they're cheaper, my company goes for qualifications
You're a foreigner yourself to about 99% of the world population. Foreigner != cheap and uncertified ;) And a lot of people still don't know that cheap usually isn't the best option either... Anyway, you make all good points, and when working in your own language, which is very convenient for domain specific terms, I guess it's difficult if your language isn't ASCII. I guess you're right on all accounts, but such pröject names still give me the shivers... :~ I'm pretty sure if I did it one tool or another would break and I'd be in for a world of pain, but I'm doing web dev so it'll break anyway :laugh:
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
I think we can agree then that I'm lucky working at a company where the boss floor isn't occupied by morons. That, and I'm lucky to work with mature tools in a mature ecosystem. That said, my condolences. At least I hope they're well-placed, every time I hear someone doing web dev, I think of http://www.commitstrip.com/en/2015/09/16/how-to-choose-the-right-javascript-framework/
-
I've always preferred the underscore and all lowercase like my_web_app and my_sql_server...kind of a pain with the added shift, but eventually muscle memory kicks in. I know this is against sql server best practices, but I don't follow stupid rules. :laugh:
Sander Rossel wrote:
like a SQL Server, which only allows lower characters.
:confused: This can be enforced?..or is it a policy thing?
"Go forth into the source" - Neal Morse
-
The everlasting struggle of developers and naming stuff... I'm not quite happy with my current project names (they're a bit longish, Company.Domain.Project.Data, for example), but what's bothering me even more at the moment is my own naming convention in Azure. I prefer PascalCased, like ThisIsMyWebApp, which is fine, except for other resources, like a SQL Server, which only allows lower characters. Long story short, I now have: MyWebApp my-sql-server mystorageaccount I'm now leaning more towards my-sql-server style for everything unless -'s are not possible, like with storage accounts. If this is what I'm worrying about everything must go pretty well, and it does, but this kind of stuff bothers me more than it should :~
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Let's see: You can call it foo or bar or fubar You can call me Ray or you can call me Day, or you can call me RayDay. You could put a number on the end. You could use an online theosaurus and find something that measn what you really want to call it. You could get one of those books of baby-names, boys names, girls names, etc, and just use the next name out of that. It works for hurricanes.
-
So would it be B****A**M************WebApp or b****-a**-m************-web-app? ;p
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
I'll take an F. I'd like to buy a vowel Pat, U! I'd like to solve that Puzzle Pat... Sorry, could NOT resist. :) On the topic, I often throw a little slang around when I get bored with naming. An example would be a module I wrote to get domain whois data. I named the function "WhoIsDis" and another "WhoIsDat" for the string data received.
-
I think we can agree then that I'm lucky working at a company where the boss floor isn't occupied by morons. That, and I'm lucky to work with mature tools in a mature ecosystem. That said, my condolences. At least I hope they're well-placed, every time I hear someone doing web dev, I think of http://www.commitstrip.com/en/2015/09/16/how-to-choose-the-right-javascript-framework/
That's how it is :laugh: Luckily, I don't do all that much front-end work... Which makes those times I do it even harder :sigh:
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
That's how it is :laugh: Luckily, I don't do all that much front-end work... Which makes those times I do it even harder :sigh:
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Now I see your problem with my non-English characters. Correct me if I'm wrong please. As far as I know, having your methods (on the server) called from clients all over the world isn't exactly uncommon making worldwide-compatible naming a hard requirement while in my case, it literally couldn't matter less as my customers get a compiled binary which, save for some places I've used RTTI, doesn't contain any names at all.
-
Now I see your problem with my non-English characters. Correct me if I'm wrong please. As far as I know, having your methods (on the server) called from clients all over the world isn't exactly uncommon making worldwide-compatible naming a hard requirement while in my case, it literally couldn't matter less as my customers get a compiled binary which, save for some places I've used RTTI, doesn't contain any names at all.
Yeah, I've done desktop development in the past and although I wouldn't want to go back it certainly has its merits. It's awesome that you can just update everything in your project without worrying something somewhere will break because it uses your API :laugh: Replace "old couples" with "desktop developers" and you know how I feel[^] ;p
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Yeah, I've done desktop development in the past and although I wouldn't want to go back it certainly has its merits. It's awesome that you can just update everything in your project without worrying something somewhere will break because it uses your API :laugh: Replace "old couples" with "desktop developers" and you know how I feel[^] ;p
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
While the comic is great, I can imagine having the pretty much same problems. Windows is an interesting example of itself, it's desktop-only (let's stick with client Windows), but Microsoft has a plethora of compatibility shims because desktop apps written for version X rely on quirks of version X and break when facing version X+1. The usual solution is to cleanly define the interface and simply not break it. The implementation can change, but who cares? Speaking from experience here, an externally-usable DLL is a part of my main product and I've changed it's guts several times in my time here, including one complete rewrite. Nobody cares because the outside stays the same. Isn't it the same in the server space? Publish an API, publish a documentation and simply don't break the API thus having all clients using it by the book not breaking? I don't have that much experience there, what's preventing web APIs from staying stable once published?
-
While the comic is great, I can imagine having the pretty much same problems. Windows is an interesting example of itself, it's desktop-only (let's stick with client Windows), but Microsoft has a plethora of compatibility shims because desktop apps written for version X rely on quirks of version X and break when facing version X+1. The usual solution is to cleanly define the interface and simply not break it. The implementation can change, but who cares? Speaking from experience here, an externally-usable DLL is a part of my main product and I've changed it's guts several times in my time here, including one complete rewrite. Nobody cares because the outside stays the same. Isn't it the same in the server space? Publish an API, publish a documentation and simply don't break the API thus having all clients using it by the book not breaking? I don't have that much experience there, what's preventing web APIs from staying stable once published?
Yeah, that's basically how it goes. It's a bit difficult for SOAP, for example, because you can't just add new properties to your API (which is sometimes necessary). You must make sure they can be omitted, for example by making them nullable. It's easier for REST, which doesn't check the incoming message and just makes the best out of it (which also has its drawbacks). I always say, the best versioning is no versioning at all. Just make sure you don't break the API. But that assumes your API is perfect from the get-go, which it rarely is. My last big rework, for example, had an API which got a complete object from the client and then created object x and object y and added some of object z. Then came some functionality where we just had to add object z and also object y was no longer necessary... The best solution was really to break that complete API and rework all clients (which, luckily, was only one) :) I think the biggest problem, in comparison with (strongly-typed) desktop development, is that your API definition can change without the client side breaking. You just send message back and forth and try to make something of it at runtime. That's (sometimes) better with SOAP, but also not always (and I like REST better anyway). So even if you're very careful, but still make a mistake, you won't find out until you test that particular service call (which isn't a simple unit test) or until it breaks in production :) I've had the same problems with some late-bound desktop development, but usually you target a specific version of a DLL, so the API is known at design time and your build simply fails.
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
The everlasting struggle of developers and naming stuff... I'm not quite happy with my current project names (they're a bit longish, Company.Domain.Project.Data, for example), but what's bothering me even more at the moment is my own naming convention in Azure. I prefer PascalCased, like ThisIsMyWebApp, which is fine, except for other resources, like a SQL Server, which only allows lower characters. Long story short, I now have: MyWebApp my-sql-server mystorageaccount I'm now leaning more towards my-sql-server style for everything unless -'s are not possible, like with storage accounts. If this is what I'm worrying about everything must go pretty well, and it does, but this kind of stuff bothers me more than it should :~
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
this kind of stuff bothers me more than it should :~
If it helps try and think of it like difference between how people are named in different parts of world. Like in the western countries there's usually a given name, followed by middle name (one of either mother or father) followed by family name. In Arabic countries it is common to find only one given name for the individual followed by an iterative ibn (meaning son of) or bint (daughter of) of all their ancestors. In south Asia there are usually two names, one given and one father's, occasionally you'd find a sect name before or after the two names. Or in some rare/unique cases as in mine you'd find three names with no relation to ancestors or sects. Just plain old names (all like first) brought together to create an ambigous meaning and make everyone in the family happy. P.S. my name translates to An Ancient Enlightened Lion. "Ancient" is the only word I can think of but the name translates to something that has been around before time. P.P.S. that rant was more for me than you, but you could still chose to see these differences and learn not to give a sh*t. :-)
-
Sander Rossel wrote:
this kind of stuff bothers me more than it should :~
If it helps try and think of it like difference between how people are named in different parts of world. Like in the western countries there's usually a given name, followed by middle name (one of either mother or father) followed by family name. In Arabic countries it is common to find only one given name for the individual followed by an iterative ibn (meaning son of) or bint (daughter of) of all their ancestors. In south Asia there are usually two names, one given and one father's, occasionally you'd find a sect name before or after the two names. Or in some rare/unique cases as in mine you'd find three names with no relation to ancestors or sects. Just plain old names (all like first) brought together to create an ambigous meaning and make everyone in the family happy. P.S. my name translates to An Ancient Enlightened Lion. "Ancient" is the only word I can think of but the name translates to something that has been around before time. P.P.S. that rant was more for me than you, but you could still chose to see these differences and learn not to give a sh*t. :-)
It's not really the same though. I get that JavaScript has a different naming convention than .NET, and I gladly stick to them, but these are all Azure services :) Everything within a project, environment or company should be named as consistently as possible so you'll never have to think about that. I know it's a utopia to be completely consistent, but you should at least get it right in one product. So why does Azure not do that? And even worse, why oh why can it only allow lower case characters (and not even special characters) in 2019? :~ Abbas (name) - Wikipedia[^] My name comes from a power tool... Just kidding, it's a popular Dutch name (an actual sander is called a 'schuurmachine', which loosely translates to 'friction machine' or, of course, a sander) :) It comes from Alexander[^] which means something like "Defender of the People" :D
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
It's not really the same though. I get that JavaScript has a different naming convention than .NET, and I gladly stick to them, but these are all Azure services :) Everything within a project, environment or company should be named as consistently as possible so you'll never have to think about that. I know it's a utopia to be completely consistent, but you should at least get it right in one product. So why does Azure not do that? And even worse, why oh why can it only allow lower case characters (and not even special characters) in 2019? :~ Abbas (name) - Wikipedia[^] My name comes from a power tool... Just kidding, it's a popular Dutch name (an actual sander is called a 'schuurmachine', which loosely translates to 'friction machine' or, of course, a sander) :) It comes from Alexander[^] which means something like "Defender of the People" :D
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
it's a popular Dutch name (an actual sander is called a 'schuurmachine', which loosely translates to 'friction machine'
That's rough!
Sander Rossel wrote:
Everything within a project, environment or company should be named as consistently as possible
If only! Integration between existing systems require (rather force) you to adopt multiple naming conventions. Just as you have ideas for better naming conventions so does all the developers of these platforms. It's almost impossible for all these developers to agree on the same thing. Now if you were to build something from scratch where selection criteria for third party tools is dominated by naming conventions...! That wouldn't leave you much options. I agree there should be one universal naming convention for all languages, but that is simply impossible, not because it can't be done. But because everyone has different ideas about them and none of them wants to back down. I know I wouldn't! if I wrote something similar I'd defend it to the end of the Earth, i.e. until I fall off the edge.
-
Sander Rossel wrote:
it's a popular Dutch name (an actual sander is called a 'schuurmachine', which loosely translates to 'friction machine'
That's rough!
Sander Rossel wrote:
Everything within a project, environment or company should be named as consistently as possible
If only! Integration between existing systems require (rather force) you to adopt multiple naming conventions. Just as you have ideas for better naming conventions so does all the developers of these platforms. It's almost impossible for all these developers to agree on the same thing. Now if you were to build something from scratch where selection criteria for third party tools is dominated by naming conventions...! That wouldn't leave you much options. I agree there should be one universal naming convention for all languages, but that is simply impossible, not because it can't be done. But because everyone has different ideas about them and none of them wants to back down. I know I wouldn't! if I wrote something similar I'd defend it to the end of the Earth, i.e. until I fall off the edge.
Abbas A. Ali wrote:
That's rough!
Hah! The joke nearly went over my head :laugh:
Abbas A. Ali wrote:
selection criteria for third party tools is dominated by naming conventions...!
I have seen products that use inconsistent naming conventions, that usually means that's not the only thing that's wrong! :rolleyes: Between systems is always difficult, but I guess in that case it's just not possible, but you can still be as consistent "as possible".
Abbas A. Ali wrote:
I agree there should be one universal naming convention for all languages, but that is simply impossible
I'm not even saying there should be one convention to rule them all, just that at least in a single product it should be. I love how ASP.NET handles it, on the .NET side I send
new { MyProperty = "Some value" }to the front-end and in JavaScript I magically get an object{ myProperty: "Some value" }. So I can use my PascalCasing in .NET, but I get my camelCasing in JavaScript, as things should be :) And it goes the other way around to! It's just a simple serializer trick, of course, but quite effective.Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
