[Development] Burning Skies: Profaned Sanctuary

[Kiyono]

Originally Posted by rohaxx0r

By the way, where do you get this ****** names? Project Ippiki-Ookami? SOUNDS LIKE **** and it's in fact, ****

Not really, it's quite a well chosen name and it describes Fang perfectly.

Now what I wanted to say, it does look like you're simply bragging about being great and stuff.
Nice GUI btw.

[Spirited]

Originally Posted by Kiyono

Not really, it's quite a well chosen name and it describes Fang perfectly.

Now what I wanted to say, it does look like you're simply bragging about being great and stuff.
Nice GUI btw.

Thanks for your opinion, and I was aware of that when I started that message... but it's either that I look like an indecisive kid or an attention loving smart-ass. I know you're not saying that I am bragging, but I know what it looks like. Just to re-establish my position, I'm just a student publicizing his project because that's what the community wanted.

I'm not too concerned about things like "You're spending too much time on the GUI" or "Your project name sucks". I take all criticism seriously, but most of it I just disagree with and continue on. I am taking the restarting thing seriously though. People have been saying I restart the project too much. This is my third attempt at a successful private server. The first was Kibou, I taught myself programming. The second was Ippiki-Ookami, I taught myself how to implement things on my own. The third is this project, and I'm developing my design. The new design is going to be much easier to develop on. Here's an example of what I mean:

 Spoiler

Here's my client from the account server (with a few things censored out). Notice how everything is there. It takes away from the true purposes of the client: to hold account information and methods, and to hold networking information and methods. It also takes away from development. The client only holds passport information. The developer will not be changing those base methods upon implementing new features. It's there to be part of the base.



Here's my new client class from the account server I just started a little more than a week ago. It makes use of inheritance and abstract classes to create a client that the developer has more room to work with. It's cleaner, easier to understand, and easier to build on. The developer sees what the base is and can work on the account features themselves without worrying about messing up the base.



It's small, but this is an example of the kinds of changes I'm doing. I'll be doing it to the map system too which is going to help me add new capabilities. Using these kinds of changes, I've smoothly implemented a lot more on top of the account server than I did before in the previous project.

If there are any other issues that are going to keep coming up that I haven't addressed yet, let me know. As I said, I want these arguments to stop and I feel we're coming closer to that. Thanks for your support.

[I don't have a username]

Two things.

Why not just do Socket.RemoteEndPoint.Address.ToString() instead calling String.Split?

And why do you use comments as summary? Wouldn't it make more sense to actually use summaries there so when you were calling the instance of ex. the client you'd get the summary instead of navigating to the variable.

[Spirited]

Originally Posted by I don't have a username

Two things.

Why not just do Socket.RemoteEndPoint.Address.ToString() instead calling String.Split?

And why do you use comments as summary? Wouldn't it make more sense to actually use summaries there so when you were calling the instance of ex. the client you'd get the summary instead of navigating to the variable.

I would if that property existed. "Socket.RemoteEndPoint.Address" doesn't exist because it's not an ip end point, it's just an abstract end point. I can use "IPAddress = (socket.RemoteEndPoint as IPEndPoint).Address.ToString();" though. I use comments to the right of things because that's a universal programming style. Having things in summary like that everywhere is too excessive and messy, even for my excessive documentation. There's a a point to where documentation harms the readability of your code.

[I don't have a username]

Originally Posted by Fаng

I would if that property existed. "Socket.RemoteEndPoint.Address" doesn't exist because it's not an ip end point, it's just an abstract end point. I can use "IPAddress = (socket.RemoteEndPoint as IPEndPoint).Address.ToString();"though.

Yeah that's what I meant.

Originally Posted by Fаng

I use comments to the right of things because that's a universal programming style. Having things in summary like that everywhere is too excessive and messy, even for my excessive documentation. There's a a point to where documentation harms the readability of your code.

No it's not universal. Summaries exists for a reason. You right side comment code functions (ex. a method etc.) not variables. You use summaries there unless you're working in languages that does not support such things ex. C++

This commenting harms the reading more than summaries though.

Just my opinion.

[Spirited]

Originally Posted by I don't have a username

Yeah that's what I meant.

No it's not universal. Summaries exists for a reason. You right side comment code functions (ex. a method etc.) not variables. You use summaries there unless you're working in languages that does not support such things ex. C++

This commenting harms the reading more than summaries though.

Just my opinion.

Just because you can put a summary on a property doesn't mean you should on normal variables; it ruins readability. The way I have it shows groups of data and the documentation to the right confirms their relationships and purposes. If I stacked it vertically with summaries, I'd have separated groups everywhere and it'd be just a huge block of code. I appreciate your feedback, but no thank you.

[CptSky]

Originally Posted by Fаng

Just because you can put a summary on a property doesn't mean you should on normal variables; it ruins readability. The way I have it shows groups of data and the documentation to the right confirms their relationships and purposes. If I stacked it vertically with summaries, I'd have separated groups everywhere and it'd be just a huge block of code. I appreciate your feedback, but no thank you.

Comments are different then documentation (summaries in C#). And, eh, without the summaries, the .NET Framework wouldn't have any documentation when using methods/classes/variables. It would be really bad. Documentation must be used. Not in private things as people shouldn't use them, comments will do the job. But, for public/exposed things, you must document them with summaries. Any company will request that. Someone who use your classes will have all the info without checking the source code. Like for the .NET Framework. With some tools, you can generate HTML documentation based on the summaries. It way more better than simpler comments.

[Spirited]

Originally Posted by CptSky

Comments are different then documentation (summaries in C#). And, eh, without the summaries, the .NET Framework wouldn't have any documentation when using methods/classes/variables. It would be really bad. Documentation must be used. Not in private things as people shouldn't use them, comments will do the job. But, for public/exposed things, you must document them with summaries. Any company will request that. Someone who use your classes will have all the info without checking the source code. Like for the .NET Framework. With some tools, you can generate HTML documentation based on the summaries. It way more better than simpler comments.

I still absolutely disagree with that. That would look absolutely hideous. Readability would be out the window. Until I meet a company that requires that form me, if someone wants to read the documentation about a variable, they should read about how it relates to other variables as well in the same group. Otherwise, it could be easily misinterpreted, even with summaries. "Go to definition" works perfectly fine and programmers in every other language without summaries do it like this. Summaries are an excuse for having dumb variable names like num1 as a public calculation constant. I'm no longer accepting suggestions about my commenting. I follow universal programming styles.

[I don't have a username]

Originally Posted by Fаng

I still absolutely disagree with that. That would look absolutely hideous. Readability would be out the window. Until I meet a company that requires that form me, if someone wants to read the documentation about a variable, they should read about how it relates to other variables as well in the same group. Otherwise, it could be easily misinterpreted, even with summaries. "Go to definition" works perfectly fine and programmers in every other language without summaries do it like this. Summaries are an excuse for having dumb variable names like num1 as a public calculation constant. I'm no longer accepting suggestions about my commenting. I follow universal programming styles.

No you don't.

[Spirited]

Originally Posted by I don't have a username

No you don't.

So you're saying my entire college, UCI, all of the books I've read on different programming langauges, and all of the people I've met so far in industry have no idea what they're talking about? I am not changing my documentation style. It's excessive as it is. I'm not going to argue about ridiculous things like this.

[I don't have a username]

Originally Posted by Fаng

So you're saying my entire college, UCI, all of the books I've read on different programming langauges, and all of the people I've met so far in industry have no idea what they're talking about? I am not changing my documentation style. It's excessive as it is. I'm not going to argue about ridiculous things like this.

Yes I'm saying that. Your college is not necessary correct just because it's a college. Programming styles are different from language to language, so you should not follow a "global programming style", but a "C# programming style", because you're programming C#.

[Korvacs]

The set of rules regarding layout of code and documentation as originally dictated by Microsoft and which is now maintained by the C# programming community, this is the closest thing to a standard you will get for documenting code.

StyleCop checks C# code for conformance to StyleCop's recommended coding styles and a subset of Microsoft's .NET Framework Design Guidelines.

You can download it here and integerate it with VS -

And please note Summary is used heavily for a fairly obvious reason, intellisense compatibility.

[Spirited]

I'm not following a language specific commenting style. That would make my code unreadable. I told you all that I will not change this. I have reasons for how I comment this way. Stop arguing on my thread please.

[CptSky]

Originally Posted by Fаng

So you're saying my entire college, UCI, all of the books I've read on different programming langauges, and all of the people I've met so far in industry have no idea what they're talking about? I am not changing my documentation style. It's excessive as it is. I'm not going to argue about ridiculous things like this.

Hopefully, not all the people who are coding have the same mentality than the people around you As I said, you're not documenting, you are commenting your code. And it's totally different. The C# language offers a powerful tools for documentation: summaries. Java offers a powerful tools for documentation: javadoc. Languages like C++ don't have documentation, but only comments, so, people made some tools like dOxygen. Oh, but they loose their time as it is so useless to use documentation... After all, there is the « Go to definition » option in some IDE. Sorry, but I don't want to go throughout all the header files, or all the source files to understand how to use the API. Anything public must be documented.

Where I work, there is this guideline:

Documenting
Document header files using dOxygen. Favor the @command format to the \command one

In fact, most people think like you. Some comments will do the job. But, eh, the VPs aren't happy of that. Each time someone want to use the API of someone else, he has to look in the entire header. When someone asked me how to use a module I did ? I just generated the HTML documentation of the module, and bam, you got a MSDN-like things to know how to use the API.

In C#, in Java, it is way better because you have things like IntelliSense which use the summaries/javadoc to show you all the information on the functions, members, etc.

That's better for people using your code. The code is clearer. And no, it doesn't allow people to use stupid naming. But, until you work with someone, it won't change anything...

------

Anyway, as you won't change your idea on that. (Which is your problem) Another point.

What is the idea to expose your variables to everyone ? All your variables which should be controlled with accessors are totally public ? What a good way to break the code...

[Korvacs]

Your probably going to find it difficult if you dont follow a standard, doxygen might be better if your looking for multi-language commenting standards. Not conforming to a standard will make things difficult if you want to work professionally in the industry.