Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (495)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 [3]
  ignore  |  Print  
  What Religion Are You?  (Read 8751 times)
0 Members and 1 Guest are viewing this topic.
Offline ra4king

JGO Kernel


Medals: 345
Projects: 3
Exp: 5 years


I'm the King!


« Reply #60 - Posted 2012-04-26 15:37:54 »

- TABS, NEVER SPACES Angry
WHY?!? Expand tabs to spaces >_<

As for curly braces, always on a new line. Partly because it's what I'm used to reading and partly because my CS teacher would not accept programs written any other way -_-

EDIT:
Oh and, this
Die, comments, die.
What is wrong with you?! Tabs are more convenient and easier to delete. I see no upsides to spaces.

And your teacher sucks balls. Grin

Offline sproingie

JGO Kernel


Medals: 202



« Reply #61 - Posted 2012-04-26 16:14:21 »

I use spaces, because if I copy and paste code into a bug or example, tabs get reformatted to something weird, or sometimes just stripped outright.  This is made worse when tabs and spaces start getting mixed, which is always going to happen when you want to align things like long parameter lists, because they never manage to line up nicely on a tab stop.  I'd use tabs everywhere if the formatting weren't so damn "unportable".
Offline Nate

JGO Kernel


Medals: 147
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #62 - Posted 2012-04-26 18:00:04 »

In my religion...

Method javadocs are necessary to document method contracts. For all my code, no method returns null and no parameter can be null unless specified in the javadocs. Eg "@param moo Can be null. @return May be null." I also use javadocs to let the user know about a default value. Eg "Default is X.". Javadocs are also needed to document what methods can be overridden by a subclass and in that case, what the default implementation does and if super must be called. Method javadocs are NOT the place for stories about how everything works, example code, unimportant implementation details, reasons why alternate implementations were not used, etc.

Class javadocs explain what the class is for and can be used to also explain how it works, but should be concise. External documentation is the place to go into great detail. Some people try to outline the entire usage of a class and end up referencing many methods in the class javadoc, but I prefer explanations on methods where it makes sense.

Implementation details do no belong in javadocs at all unless it is somehow relevant to the user (eg, big O). Non-javadoc comments often contain implementation details and are necessary when they help code to be understood. Think of them as "private" comments. I use them extremely sparingly and as others have mentioned, often code can be written so that non-javadoc comments are not needed. However, javadoc comments are different and are needed to clarify method contracts so that people know how to use your code.

Remember that comments do not replace real documentation. As such, keep them concise and simple, incomplete sentences are fine. In ALL my comments and documentation I try to avoid the word "you". Give it a try, it makes everything more professional and more concise.

Of course, all this is only relevant when writing OSS libraries or when coding for work where others may need to maintain your code. For private projects, do whatever the hell you want.

I use spaces, because if I copy and paste code into a bug or example, tabs get reformatted to something weird, or sometimes just stripped outright.  This is made worse when tabs and spaces start getting mixed, which is always going to happen when you want to align things like long parameter lists, because they never manage to line up nicely on a tab stop.  I'd use tabs everywhere if the formatting weren't so damn "unportable".

So don't align things. No ASCII art in source code! I use Eclipse to format, so never have mixed tabs and spaces. Tabs are better because the individual can decide how wide they want a tab. I prefer a 3 column tab, as 2 columns isn't quite enough, and 4 is a bit too much and 3 gives me horizontal space.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #63 - Posted 2012-04-26 21:10:26 »

Javadoc is one of the saviours of Java, mind. There's nothing remotely as pervasive or supported for any other language I've ever used or seen.

Cas Smiley

Offline gimbal

JGO Knight


Medals: 25



« Reply #64 - Posted 2012-04-27 08:41:04 »

In my religion...

Method javadocs are necessary to document method contracts.

Such a short sentence to capture the entire essence of it - but it does. Win!
Offline h3ckboy

JGO Coder


Medals: 5



« Reply #65 - Posted 2012-04-27 08:55:42 »

totally option two, I usually do not care in other people's code, but when I look at my one, that extra line helps me to better differentiate between methods/loops which when I am scrolling through huge classes is very helpful Smiley.
Offline StumpyStrust
« Reply #66 - Posted 2012-04-27 09:04:08 »

totally option two, I usually do not care in other people's code, but when I look at my one, that extra line helps me to better differentiate between methods/loops which when I am scrolling through huge classes is very helpful Smiley.

hehe no kidding. Maybe I am just not experienced enough but when I have 1k plus lines of code I very much like to see exactly what is what. Later as I will get more experianced I may go the other way so, as someone has already said, I see more code on the screen at once.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #67 - Posted 2012-04-27 15:32:13 »

Javadoc is API documentation that just happens to be written as specially formatted comments.  It's definitely a different thing than code comments, and I can't say enough how huge a fan I am of writing lavish API documentation.  Actually I'm a huge fan of someone else writing lavish documentation, because I'm terrible about it Smiley
Pages: 1 2 [3]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (12 views)
2014-09-19 03:14:18

Dwinin (30 views)
2014-09-12 09:08:26

Norakomi (57 views)
2014-09-10 13:57:51

TehJavaDev (79 views)
2014-09-10 06:39:09

Tekkerue (40 views)
2014-09-09 02:24:56

mitcheeb (62 views)
2014-09-08 06:06:29

BurntPizza (45 views)
2014-09-07 01:13:42

Longarmx (30 views)
2014-09-07 01:12:14

Longarmx (36 views)
2014-09-07 01:11:22

Longarmx (36 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!