Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (115)
games submitted by our members
Games in WIP (562)
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]
  ignore  |  Print  
  Quality Code  (Read 7228 times)
0 Members and 1 Guest are viewing this topic.
Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #30 - Posted 2006-11-17 09:22:43 »

formatting should become ambiguous as formatting is mearly presentation.

formatting your code doesn't influence how the code works. ppl should be allowed to use what ever ugly(yes ugly only my formatting is the right one!) formatting they want.


[client] --> (re-)formatting (using server style) --> [server/repository]
[client] <-- (re-)formatting (using client style) <-- [server/repository]

1. [client[DIFF]] [DIFF] <-- (re-)formatting (using client style) <-- [server/repository]
2. Merge
3. [client[Merged]] --> (re-)formatting (using server style) --> [server/repository]

appearandly theres are checking-in hooks, if there are check-out hooks then we can implent this and client with check-out hooks can use w/e they want in there only formatting world. Lets call it format-round tripping, if that makes it clearer. And since we work at the same level of abstraction the con's of the other/normal 'round tripping' are absent.

although it is useless in the light of the above, I'd like to know that my preference goes to sticking the { at the end. And no I don't do it to save lines, I do it because it's easier to reconise indents and use indents to reconise structure, then it is to actually read anything. And it's inconsistend or do you also write
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
for
{

}

if
{

}

static
{

}

syncronised(mutex)
{

}


but as I said who cares.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #31 - Posted 2006-11-17 10:48:27 »

formatting should become ambiguous as formatting is mearly presentation.

formatting your code doesn't influence how the code works. ppl should be allowed to use what ever ugly(yes ugly only my formatting is the right one!) formatting they want.


[client] --> (re-)formatting (using server style) --> [server/repository]
[client] <-- (re-)formatting (using client style) <-- [server/repository]

1. [client[DIFF]] [DIFF] <-- (re-)formatting (using client style) <-- [server/repository]
2. Merge
3. [client[Merged]] --> (re-)formatting (using server style) --> [server/repository]

appearandly theres are checking-in hooks, if there are check-out hooks then we can implent this and client with check-out hooks can use w/e they want in there only formatting world. Lets call it format-round tripping, if that makes it clearer. And since we work at the same level of abstraction the con's of the other/normal 'round tripping' are absent.

Just as cylab already mentioned, checkin hooks will cause a lot of diffs, as well as check-out-hooks will.

although it is useless in the light of the above, I'd like to know that my preference goes to sticking the { at the end. And no I don't do it to save lines, I do it because it's easier to reconise indents and use indents to reconise structure, then it is to actually read anything. And it's inconsistend or do you also write
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
for
{

}

if
{

}

static
{

}

syncronised(mutex)
{

}


Of course I do. And all the others prefering next-line-braces will also do. What did you think?

Marvin
Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #32 - Posted 2006-11-17 13:34:29 »

Just as cylab already mentioned, checkin hooks will cause a lot of diffs, as well as check-out-hooks will.

check out hook will eliminate diffs.
formatting1 -> conversion on check in --> formatting2[server]
since everything thats checked in at the server is in formatting2 it will not cause diff's on the server
formatting2[server] --> conversion on check out --> formatting1
since everything thats checked out at the client is in formatting1 it will not cause diff's on the client

diff's will occour wenn it's only formatted one way, not wenn it's two/both ways.

perhaps a more programmer like abstract example will work.
say at the server I'm using 10 digit system.
Theres a 4 on the server.
The client attemps to check the 4 out
the check-out hook is run and the 4 is converted into a 2 digit system resulting into 100
The client then checks in the 100
the check-in hook is run converting it to a 4
4 is compaired to the excisting 4 causing no diff (4 eq 4) <-> true
if the client checks it out again it converts it back to 2 digit system resulting into 100
again it's the same as the excisting is 100 and the server returns 100.

some clairifications:
the check-out hook is not at the server but at the client.
code formatting conversion doesn't require knowlage on the excisting code formatting.  (as opposed to the example where 100 could be interpered as a 100 (10system) as well as 4(2digit) as long as the code is syntaxly correct there are no problems but since there are undoubtly also check-in hooks that could check the syntax it shouldn't cause problems.

Of course I do. And all the others prefering next-line-braces will also do. What did you think?

Marvin
I usually see ppl going about it as such:
http://www.google.com/codesearch?q=+import+show:nOOdPlEDeFg:cIL_WEimU_M:jKlW_1_QSDY&sa=N&cd=107&ct=rc&cs_p=http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6a/src/mozilla-source-1.6a.tar.bz2&cs_f=mozilla/security/nss/lib/dev/devtoken.c#a0

I having looked ad some pieces of code where it is consistenly applied I do find it better, there is still a gab. I can live with iether of the 3

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #33 - Posted 2006-11-17 13:43:35 »

You can only imagine how many great lines would have been coded, if this thread wasn't started.

Sometime you can just agree to disagree, move on, and do something useful with your valuable time.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #34 - Posted 2006-11-17 14:20:26 »

You can only imagine how many great lines would have been coded, if this thread wasn't started.

Sometime you can just agree to disagree, move on, and do something useful with your valuable time.
Yeah but you can see how many people have come on the xith3d boards because of that.. okay I'm not an ad-master but I find interesting to harvest others' knowledge.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #35 - Posted 2006-11-17 14:23:57 »

It's not like they come to the 'Xith board', they just click 'show unread posts', so you'll probably
never see them again around here, some may not even have noticed they are posting on a Xith board.

Finally, would you really want to have all those visitors, on your Xith board that do not chat about Xith
but something that is a matter of taste? Nobody will change their taste because of this whole thread.

My final words here... or I'd be joining this time-wasting effort Smiley

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #36 - Posted 2006-11-17 14:31:56 »

It's not like they come to the 'Xith board', they just click 'show unread posts', so you'll probably
never see them again around here, some may not even have noticed they are posting on a Xith board.
Yeah and? They're still disseminating knowledge.. that's what's count (for me)

Finally, would you really want to have all those visitors, on your Xith board that do not chat about Xith
but something that is a matter of taste? Nobody will change their taste because of this whole thread.
Yeah but maybe you missed the thing about server-side hook-in testing, and automatic reformatting.. which is pretty interesting anyway...

My final words here... or I'd be joining this time-wasting effort Smiley
Cheesy

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline DzzD
« Reply #37 - Posted 2006-11-17 14:33:22 »

Quote
It's not like they come to the 'Xith board', they just click 'show unread posts', so you'll probably
never see them again around here, some may not even have noticed they are posting on a Xith board.

absolutly true for me... never seen that was xith thread and I just clicked "unread post"...

Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #38 - Posted 2006-11-17 14:46:51 »

brackets have nothing to do with if/else/while and other statements in any language, so i dont understand why it seems so logical to open bracket at end of line

to me they define why the block is there in the first place.

1  
2  
3  
4  
public realyRealyRealyRealyRealyRealyRealyRealyRealyRealyRealyRealyRealyLongNaaaaammmee = new Object();
{
 doSomething();
}

is the same in both formattings.
ppl who use the new line for { have to check the end for a ';' , ppl using the at the end of line { could have savely presumed a simple code block

if else etc and even 'nothing' saids something about the code block namely wenn it execute or what is defined in the block. even the absance of anything describes something about the code block.

I wouldn't care about if brackets have nothing or something to do with other statements I care about that those statements have somethign to do with the brackets.

"The more brackets you go into the less interesting it gets."

I don't have a vote on this and I shouldn't anyways, does that mean I shouldn't share insigths. I like to be proven wrong or tested on anything I do, as it improves me.

I better get back to work, I have to catch up on all those lost lines of code  Tongue

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Pages: 1 [2]
  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 (21 views)
2014-09-21 02:42:18

BurntPizza (15 views)
2014-09-21 01:30:30

moogie (15 views)
2014-09-21 00:26:15

UprightPath (25 views)
2014-09-20 20:14:06

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

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

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

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

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

mitcheeb (70 views)
2014-09-08 06:06:29
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!