Code reading
[31 byte] By [agerard2a] at [2007-10-2 15:21:51] 
How does Java () "work"?
> How does Java () "work"?Sorry, that might be more of a "BluePrints" question. (What is the difference again beetween "Patterns" and "BluePrints"?)
agerard2a at 2007-7-13 14:32:27 >
patterns are tried-and-true solutions to specific object-oriented programming problems.
i think of blueprints as worked-out architectures for specific problems.
i'd say blueprints are larger in scope than patterns, but i can see where an argument might be made that a blueprint is nothing more than a large-scale pattern.
depends on how you define the terms.
%
duffymoa at 2007-7-13 14:32:27 >
> patterns are tried-and-true solutions to specific
> object-oriented programming problems.
>
> i think of blueprints as worked-out architectures for
> specific problems.
>
> i'd say blueprints are larger in scope than patterns,
> but i can see where an argument might be made that a
> blueprint is nothing more than a large-scale
> pattern.
>
> depends on how you define the terms.
>
> %
Thank you very much, now at least I totally can't understand why Java() absolutely has to divide it into two separate Forums.
Now - then no one can help me in understanding how Java code works ... for h... - how you use it.
Almost every time I look at a code sample, I simply can't understand why it is written the way it is. Of course, probably no one could understand, why my code is written "my way". (Saying I try to keep it as linear -> strait forward as possible probably won't help either. ... where do you place the main method, ...)
Probably(?) this is not a place to share experiences.
( -> Or maybe I'll really have to reask it in "BluePrints"...?)
agerard2a at 2007-7-13 14:32:27 >
> Now - then no one can help me in understanding how
> Java code works ... for h... - how you use it.
>
> Almost every time I look at a code sample, I simply
> can't understand why it is written the way it is.
These are both very, very general statements and nobody can help you based on this.
Why don't you post an actual code sample and indicate clearly which parts you don't understand, or don't understand why they are written the way they are. That would be something that other people can respond to.
Lokoa at 2007-7-13 14:32:27 >
> These are both very, very general statements and
> nobody can help you based on this.
> Why don't you post an actual code sample and indicate
> clearly which parts you don't understand, or don't
> understand why they are written the way they are.
So you would say I'm not so completely wrong in "Patterns..."?
The last example e.g. I couldn't understand why ... is: http://java.sun.com/products/java-media/jmf/2.1.1/solutions/Transcode.java
Where is the main method, why does it have to be where it is?... What does it do (not statically) -> what is the instantiation of "Transcode" for (at least I would have less a hard time understanding if it would be a "TranscodeEngine")?
Where does it (all) begin ... where does it continue -> how and why, like that?
What does it (basically?) do: write a file(?) - isn't anything else "linear" ... (mostly statical?) "preliminaton(s)"?
Do you all code like that and find it very readable, or maybe have any other reason to do things that way (I would be the only one having a harder time than necessary, for understanding a code sample, that might (only?) should help me understand how it >generally< works)?
agerard2a at 2007-7-13 14:32:27 >
> So you would say I'm not so completely wrong in
> "Patterns..."?
I'm not commenting on whether or not this is the right forum for your question. If a lot of people feel so, it sort of is :)
> The last example e.g. I couldn't understand why ...
> is:
> http://java.sun.com/products/java-media/jmf/2.1.1/solu
> tions/Transcode.java
>
> Where is the main method, why does it have to be
> where it is?
Do you mean you can't find it? Its the one with this signature: public static void main(String [] args).
Only the author knows why it is there; you can order methods like you want to. Everyone probably has their own habits but readability by others should be the first concern. This not really a fundamental issue; in practice a developer has to learn to get used to reading/changing code using any conventions.
>... What does it do (not statically) ->
> what is the instantiation of "Transcode" for (at
> least I would have less a hard time understanding if
> it would be a "TranscodeEngine")?
Again this is a personal preference and again readability by someone else who sees it the first time, should be the first concern in choosing class names. Personally I would call it Transcoder but Transcode is fine by me; the class represents a single operation and doIt is its only public method so it's okay to name the class after the operation rather than an entity performing it.
>
> Where does it (all) begin ... where does it continue
> -> how and why, like that?
I'm not quite sure what you mean. The program starts at the beginning of main and continues from there, calling other methods, until a call to System.exit. What order the methods are in doesn't affect the runtime behaviour, if that's your question.
> What does it (basically?) do: write a file(?) - isn't
> anything else "linear" ... (mostly statical?)
> "preliminaton(s)"?
I don't know what you mean by this.
> Do you all code like that and find it very readable,
Personally I don't, and no I don't find that sample very readable. I usually have a lot more and shorter methods with descriptive names and I provide test code demonstrating what my classes do. I tend to order my methods mostly from the point of view of a user of my class; publics first (ctors then non-static methods then statics), then the other accesses.
> or maybe have any other reason to do things that way
> (I would be the only one having a harder time than
> necessary, for understanding a code sample, that
> might (only?) should help me understand how it
> >generally< works)?
The only concerns, IMO, are readability, maintainability, flexibility and testability. Usually these all come down to the same results.
There are no strict rules for this; my only rule is that code is well-written if nobody has a hard time understanding it, which is an ideal of course. And, in practice, you have to learn to live (a lot) with code written worse than the sample you provided. This is not a Java-specific issue; it's in human nature ;-)
Lokoa at 2007-7-13 14:32:27 >
> > So you would say I'm not so completely wrong in
> > "Patterns..."?
>
> I'm not commenting on whether or not this is the
> right forum for your question. If a lot of people
> feel so, it sort of is :)
>
As long as there's the chance to get "useful" answer ( ... thank YOU very much!!) (...)
> > Where is the main method, why does it have to be
> > where it is?
>
> Do you mean you can't find it? Its the one with this
> signature: public static void main(String [] args).
> Only the author knows why it is there; you can order
> methods like you want to. Everyone probably has their
> own habits but readability by others should be the
> first concern. This not really a fundamental issue;
> in practice a developer has to learn to get used to
> reading/changing code using any conventions.
>
Here's the word: probably one might consider this under ... personal ( ... common?) "code conventions" ( ... for readability?).
Personally I put the main method normally at the end -> then I sort of know where to start, even without having to search for " main(", and with IDE (netbeans) I can even jump to the beginning of main ( -> goto corresponding >bracket<). It won't come in conflict with any constructors ((only?) I noramlly put before the methods), any other method, fields or even inner classes (before anything else class "members" (fields, methods, ...) except global constants: ... static final ...)).
> >... What does it do (not statically) ->
> > what is the instantiation of "Transcode" for (at
> > least I would have less a hard time understanding
> if
> > it would be a "TranscodeEngine")?
>
> Again this is a personal preference and again
> readability by someone else who sees it the first
> time, should be the first concern in choosing class
> names. Personally I would call it Transcoder but
> Transcode is fine by me; the class represents a
> single operation and doIt is its only public method
> so it's okay to name the class after the operation
> rather than an entity performing it.
>
What I mean is instantiation. An >engine< is a ( ... >real world<) thing ... that might have ((may)be more logical for me) an object instance. A mostly statical "main application" ( -> "Transcode") is not - therefor instantiate it what for (performance, preferences, ... - personally I couldn't understand if someone would say for readability -> what might bring the >sample code< "issue" back (at least for me))?
> >
> > Where does it (all) begin ... where does it
> continue
> > -> how and why, like that?
>
> I'm not quite sure what you mean. The program starts
> at the beginning of main and continues from there,
> calling other methods, until a call to System.exit.
> What order the methods are in doesn't affect the
> runtime behaviour, if that's your question.
>
See above and below: where is main, what does it do(...)
> > What does it (basically?) do: write a file(?) -
> isn't
> > anything else "linear" ... (mostly statical?)
> > "preliminaton(s)"?
>
> I don't know what you mean by this.
>
(In the end) I'd say Transcode takes data (a file) processes it -> precisely "transcodes" it, and writes it back to a file. So in the end ... what does it do: it writes a file - and "straight backward", it has to do all previous ops to know what to write (how I try to analyze it to find out how it works -> go >backwards<).
> > Do you all code like that and find it very
> readable,
>
> Personally I don't, and no I don't find that sample
> very readable. I usually have a lot more and shorter
> methods with descriptive names and I provide test
> code demonstrating what my classes do. I tend to
> order my methods mostly from the point of view of a
> user of my class; publics first (ctors then
> non-static methods then statics), then the other
> accesses.
>
That's probably rather different with me. Where's not "apropriate"(?), I don't code OO, but more linear (procedural?) -> workflow(?), what happens in the main method -> it begins at the beginning, goes more or less "linear" through (the necessary ops), and normally ends at the end (for me maybe only with the exception of multi...(task-/)threading -> (G)UI (swing) stuff ... where you (normally?) really need a "System.exit(...)").
Normally I really rather prefer OO for "real" Objects, where instantiation makes sence for me (a "DataObject" I have to save, a screen object (dialog, ...) I have to display, maybe an >engine< / >factory< ... that has to perform tasks, ...) .
> > or maybe have any other reason to do things that
> way
> > (I would be the only one having a harder time than
> > necessary, for understanding a code sample, that
> > might (only?) should help me understand how it
> > >generally< works)?
>
> The only concerns, IMO, are readability,
> maintainability, flexibility and testability. Usually
> these all come down to the same results.
> There are no strict rules for this; my only rule is
> that code is well-written if nobody has a hard time
> understanding it, which is an ideal of course. And,
> in practice, you have to learn to live (a lot) with
> code written worse than the sample you provided. This
> is not a Java-specific issue; it's in human nature ;-)
Maybe (Probably?) I just wonder how far (Java...?) "code conventions" (also / not only for readability for everyone -> why I ask YOUR(s) opinion) should span.
agerard2a at 2007-7-13 14:32:27 >
> So you would say I'm not so completely wrong in "Patterns..."?I think you're completely wrong about everything you've said. Little of it makes sense.Sounds like you don't know much about programming in general or Java in particular.%
duffymoa at 2007-7-13 14:32:27 >
> > So you would say I'm not so completely wrong in> "Patterns..."?> > I think you're completely wrong about everything> you've said. Little of it makes sense.I seriously thought it was just me.Thank you.
tsitha at 2007-7-13 14:32:27 >
> As long as there's the chance to get "useful" answer
> ( ... thank YOU very much!!) (...)
How useful the answers you get are, depends solely on how clear your questions are. Yours still aren't, to be honest. I'm just in a forgiving mood today :-)
> Here's the word: probably one might consider this
> under ... personal ( ... common?) "code conventions"
> ( ... for readability?).
Yes. Whether these conventions are personal depends on where you work. Some places don't care and I use my own habits; other places have guidelines in place and I either follow them or debate why I think some of them are really bad ideas and get them changed or accept them anyway.
> What I mean is instantiation. An >engine< is a ( ...
> >real world<) thing ... that might have ((may)be more
> logical for me) an object instance. A mostly statical
> "main application" ( -> "Transcode") is not -
> therefor instantiate it what for (performance,
> preferences, ... - personally I couldn't understand
> if someone would say for readability -> what might
> bring the >sample code< "issue" back (at least for
> me))?
What is your question? Do you mean "why isn't everything in class Transcode static so I don't have to instantiate it" - that would be an actual question. My answer would be that it's the wrong question to ask and probably an artefact from working with strictly procedural languages and trying to fit OO/Java into that way of thinking. And also that in this case it doesn't really matter much to being able to understand the code (IMHO).
> (In the end) I'd say Transcode takes data (a file)
> processes it -> precisely "transcodes" it, and writes
> it back to a file. So in the end ... what does it do:
> it writes a file - and "straight backward", it has to
> do all previous ops to know what to write (how I try
> to analyze it to find out how it works -> go
> >backwards<).
Again it's hardly clear what your question is. I'm not going to read every line of code in your sample; I don't think anybody here is going to do that. The way I usually find out how code works is by first reading it on high-level, then running the test code, perhaps stepping through it in a debugger. If there is no test code, I write the test code, which teaches me a lot already, and then step through it. If I really don't get the time to do it this way, I'll have to make do with just reading and some mental debugging and stepping.
> Normally I really rather prefer OO for "real"
> Objects, where instantiation makes sence for me (a
> "DataObject" I have to save, a screen object (dialog,
> ...) I have to display, maybe an >engine< / >factory<
> ... that has to perform tasks, ...) .
Okay.
> Maybe (Probably?) I just wonder how far (Java...?)
> "code conventions" (also / not only for readability
> for everyone -> why I ask YOUR(s) opinion) should
> span.
This is, at best, an academic question with no real world relevance.
In any case, and I'm gonna wrap this up... Code conventions are not an end, they are a means to the end of producing workable code. So they should span as far as necessary, depending on the experience level of the team, the scope and nature of the project, how much you can get everyone to agree and follow them, etc... Any attempt at coming up with the "definitive guidelines and conventions" is futile, it really is.
In all honesty, and I am not berating you or questioning your right to ask these questions or anything, but it seems that the point of view from which you are asking all this, is quite alien to most people here.
The only advice I can give you is to find and read a good tutorial on Java and OO. My personal favorite would be Bruce Eckel's "Thinking in Java".
Lokoa at 2007-7-13 14:32:27 >
> The only advice I can give you is to find and read a
> good tutorial on Java and OO. My personal favorite
> would be Bruce Eckel's "Thinking in Java".
Maybe we'll start to get somewhere (even if I don't know if you read the same version I skimmed over (overflew?), but ...)
Try once to rollup or rolldown your home window(s) (if you're not just living in some futuristic...(?) home) -> That's why I probably would define Window as a inner class of Car, probably even name it "CarWindow" and then even make extend / implement it some "(Base/Basic...)Window". (More "real world"?)
Of course, it's only a simple sample there, so it would probably be rather superfluous there, whereas in Transcode, personally I try to understand the -> _video_ "algorithm" and I think for me there would be the possibility to make it easier and faster for me to understand, if the implementation was more "linear".
That's why I don't understand the instantiation and the "doIt()" rather than just do everything in main (except the command line parsing stuff, that does nothing to do to help me understand the video, JMFstuff) as I - am I the only one - have to start at "main" anyway.
If I'm really the only one (only thinking?) I need longer than necessary to understand (I'm talking here about the sample(s)) algorithms, so i'll have to live with that. But if I'm not ... ok I don't really care about the worldwide lost time and money (and nerves?) and the postponed release dates(...?)
(Now, if you don't understand ... anything, if you're up to it, tell me what it (all) is exactly, maybe I'll be able to learn ... maybe even change something, and do it better next time.)
agerard2a at 2007-7-13 14:32:27 >
>
> If I'm really the only one (only thinking?) I need
> longer than necessary to understand (I'm talking here
> about the sample(s)) algorithms, so i'll have to live
> with that.
I am not sure I have ever seen anything where I thought the documentation was perfect.
I remember a 3rd party library for C++ years ago which had excellent documentation. But I still had to look at the source code at least once.
I suspect it isn't possible for it to be perfect. By the time one writes the examples for all possible scenarios then the documentation is so huge that it is unusable.
And many things don't even come close to being perfect.
Experience helps one to guess at what the documentor really meant and it also helps in limiting the things that one must try when the documentation doesn't cover it at all.
jschella at 2007-7-13 14:32:27 >
> >
> > If I'm really the only one (only thinking?) I need
> > longer than necessary to understand (I'm talking
> here
> > about the sample(s)) algorithms, so i'll have to
> live
> > with that.
>
> I am not sure I have ever seen anything where I
> thought the documentation was perfect.
>
> I remember a 3rd party library for C++ years ago
> which had excellent documentation. But I still had
> to look at the source code at least once.
>
> I suspect it isn't possible for it to be perfect. By
> the time one writes the examples for all possible
> scenarios then the documentation is so huge that it
> is unusable.
>
> And many things don't even come close to being
> perfect.
>
> Experience helps one to guess at what the documentor
> really meant and it also helps in limiting the things
> that one must try when the documentation doesn't
> cover it at all.
Maybe why I asked about your experiences (opinions?), to maybe agree on "easier readable code: what might that be?" -> for a majority of readers and then maybe defining some "code conventions" (maybe only for ... "sample" code -> has no(?) performance (...?) issues), a majority (or only ones sample "publishers") might stick to, to might make life a little easier for some? (Can't things (ever?) evolve?)
(Maybe losing anything: time, money, ... more than necessary (where maybe preventable), maybe only just bugs myself?)
agerard2a at 2007-7-13 14:32:27 >
JMO, but your writing style would be better served if you left out all those parenthetical remarks, questions marks, arrows, stray punctuation, etc. I find your thoughts hard to follow, and the writing style you've evolved does not help at all.%
duffymoa at 2007-7-13 14:32:27 >
>
>
> Maybe why I asked about your experiences (opinions?),
> to maybe agree on "easier readable code: what might
> that be?" -> for a majority of readers and then maybe
> defining some "code conventions" (maybe only for ...
> "sample" code -> has no(?) performance (...?)
> issues), a majority (or only ones sample
> "publishers") might stick to, to might make life a
> little easier for some? (Can't things (ever?)
> evolve?)
>
There is nothing that I have ever seen that suggests that a certain style makes anything objectively easier to read.
There are many subjective opinions about what is readable though.
However I wasn't commenting on code but rather documentation. Documentation might or might contain code examples.
jschella at 2007-7-20 22:34:27 >
> >
> >
> > Maybe why I asked about your experiences
> (opinions?),
> > to maybe agree on "easier readable code: what
> might
> > that be?" -> for a majority of readers and then
> maybe
> > defining some "code conventions" (maybe only for
> ...
> > "sample" code -> has no(?) performance (...?)
> > issues), a majority (or only ones sample
> > "publishers") might stick to, to might make life a
> > little easier for some? (Can't things (ever?)
> > evolve?)
> >
>
> There is nothing that I have ever seen that suggests
> that a certain style makes anything objectively
> easier to read.
>
This isn't objective, but, Lisp aside, I think overuse of parentheses cuts down on readability.
tsitha at 2007-7-20 22:34:27 >
> This isn't objective, but, Lisp aside, I think> overuse of parentheses cuts down on readability.Personally I think Lisp is a reinforcing example of your overall point.
dcmintera at 2007-7-20 22:34:27 >
> JMO, but your writing style would be better served if
> you left out all those parenthetical remarks,
> questions marks, arrows, stray punctuation, etc. I
> find your thoughts hard to follow, and the writing
> style you've evolved does not help at all.
>
> %
At first when I read through the thread I laughed out loud and thought the very same thing. But after closer inspection, I think the OP is struggling in a huge way with English. My guess is the intent is to leave in the "optional" words in case the wrong translation is being made. The extra words are optional translations. They are there to help communicate the question.
if you read the same version I skimmed over (overflew?), but ...)
Like is it over or overflew? Which is correct? The OP isn't sure so includes them both.
Of course I could be wrong. And I agree it is unfortunate because it is very confusing. I'm not sure I even understand what is being asked or discussed here.
nantucketa at 2007-7-20 22:34:27 >
> How does Java () "work"?Very carefully... That's how.
Java_Jaya at 2007-7-20 22:34:27 >
> That's probably rather different with me. Where's not
> "apropriate"(?), I don't code OO, but more linear
> (procedural?) -> workflow(?), what happens in the
> main method -> it begins at the beginning, goes more
> or less "linear" through (the necessary ops), and
> normally ends at the end (for me maybe only with the
> exception of multi...(task-/)threading -> (G)UI
> (swing) stuff ... where you (normally?) really need a
> "System.exit(...)").
Then why burden yourself with Java. You should stick to C (Not C++) or Assembly, Cobol, Basic... Stay in the 70's man... The rest of us will keep on trucking through the new century.
J
Java_Jaya at 2007-7-20 22:34:27 >
Other Topics New Topic
Other Topics Hot Topic
Other Topics
All Classified
- Archived Forums
- Enterprise & Remote Computing
- Java Essentials
- Desktop
- Core
- Solaris Operating System
- Security
- Database Connectivity
- Java Mobility Forums
- Web & Directory Servers
- Development Tools
- Application & Integration Servers
- Java HotSpot Virtual Machine
- Other Topics
- E-Mail, Calendar, & Collaboration
- Developer Tools
- General
- Administration Tools
- Sun Hardware
- Storage Forums
- Java Enterprise System
- StarOffice
- Open Source Technologies
- BigAdmin
- Real-Time
- Java Coding