 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2007hi
i want to search a particular word in the file using java. can u give any specific link for this regards kavitha >i want to search a particular word in the file using java. > can u give any specific link for this > > regards > kavitha Read the file Check the input for the word If the word is found then display something Repeat. . . . . Maybe it would be better if you showed us what you had tried, specifically what is not working and we can work from there. -- LTP :) Hi kavitha, u can try out the following code , it allows wild cards ,but is case sensitive.Please tell me if u need that too?? import java.io.BufferedReader; import java.io.FileNotFoundException; import java.io.FileReader; import java.io.IOException; import java.util.regex.Matcher; import java.util.regex.Pattern; public class RnD { public static void main(String[] args) { Pattern pattern = Pattern.compile("SAXELBY"); BufferedReader reader = null; try { int lineNumber=0; reader = new BufferedReader( new FileReader("C:\\00000001.txt")); while (true) { lineNumber++; String curline = reader.readLine(); if (curline == null) { break; } Matcher matcher = pattern.matcher(curline); while (matcher.find()) { System.out.println("at "+lineNumber+" "+ matcher.group() + " start=" + matcher.start() + " end= " + matcher.end()); } } } catch (FileNotFoundException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } finally { if (reader != null) { try { reader.close(); } catch (IOException e1) { e1.printStackTrace(); } } } } } thanks lab > Hi kavitha, > u can try out the following code , it allows wild cards ,but is case > sensitive.Please tell me if u need that too?? The word is "you", not "u". The trouble with doing someone's homework for them is that you deprive them of an education. That's a big waste of their tuition. > import java.io.BufferedReader; > import java.io.FileNotFoundException; [quoted text clipped - 6 lines] > > public static void main(String[] args) { Please do not embed TABs in Usenet posts. > Pattern pattern = Pattern.compile("SAXELBY"); What is this regex? How did you come up with it? There was no indication in the OP for this. > BufferedReader reader = null; > try { > int lineNumber=0; > reader = > new BufferedReader( > new FileReader("C:\\00000001.txt")); Hard-coded strings. Tsk, tsk. Where did you come up with it? There was no indication in the OP for this. > while (true) { To depend on exceptions as flow control is a bad practice. > lineNumber++; > String curline = reader.readLine(); [quoted text clipped - 14 lines] > } catch (FileNotFoundException e) { > e.printStackTrace(); Ooh, you ignore the exception and move on. This is good for examples, bad in practice. This is also a good place to introduce logging statements. > } catch (IOException e) { > e.printStackTrace(); [quoted text clipped - 4 lines] > } catch (IOException e1) { > e1.printStackTrace(); Those darn TABs. > } > } > } > > } > } - Lew [sNip] >> while (true) { > > To depend on exceptions as flow control is a bad practice. [sNip] This typically occurs because the reserved word "goto" isn't implemented. There are situations where "goto" would be very useful, such as: 0. An alternative to "break label" since label is currently limited in where it can be located (such code could be easier to read) 1. The ability to share code between methods within a class, which all end with the same functionality (this could be more efficient than calling another method; javac would need to generate errors such as attempts to access variables that belong to different methods, return type mismatches, etc.) I do agree with your view that infinite loops that depend on exceptions are a bad practice. Using conditionals to trigger a "break" would also be better handled by making that the focus of the loop -- and if they need to compare afterwards, then "do { ... } while (condition);" can certainly solve that problem.  SignatureRandolf Richardson - kingpin+nntp@lumbercartel.ca The Lumber Cartel, local 42 (Canadian branch) http://www.lumbercartel.ca/ > 1. The ability to share code between methods within a class, > which all end with the same functionality (this could be more > efficient than calling another method; javac would need to generate > errors such as attempts to access variables that belong to different > methods, return type mismatches, etc.) That's headache-inducing and makes the code far less readable (thus it runs counter to your item 0). Why do you think the MINISCULE overhead in a local method call is worth the MAJOR hassle of having to look in so many places to follow the flow of a method? Not to mention that you still would only be able to goto code that completes with a return, and the label's method would need to have the same return type and with a compatible throws clause, and the class file spec would need to add a global label table... Refactor the shared code into a private final method and trust the runtime to inline the code as necessary. Or wait for closures to be implemented. > This typically occurs because the reserved word "goto" isn't > implemented. There are situations where "goto" would be very useful, > such as: I totally disagree. Assemblers need "goto" but no decent HLL does. That goes for COBOL too and before you ask, yes I've written GOTO-less COBOL. I have never used goto (or needed it) in C and see no need for it in Java. > 0. An alternative to "break label" since label is currently > limited in where it can be located (such code could be easier to read) I don't use this construction in C either and, again, don't need it. > 1. The ability to share code between methods within a class, > which all end with the same functionality (this could be more efficient > than calling another method; javac would need to generate errors such as > attempts to access variables that belong to different methods, return > type mismatches, etc.) Encapsulating the code in a private method makes for more readable code as well as eliminating code duplication. > I do agree with your view that infinite loops that depend on > exceptions are a bad practice. Using conditionals to trigger a "break" > would also be better handled by making that the focus of the loop -- and > if they need to compare afterwards, then "do { ... } while (condition);" > can certainly solve that problem. Yes - but that's a result of classes that throw exceptions when their methods would be better off returning control values. IMO if you have to use exceptions to control normal logic flow in code that calls the class methods merely demonstrates bad class design. I never design classes/methods that force their user to control normal logic flow with exceptions: I use methods that return control information (e.g hasNextObject() to control loops). Similarly, my constructors never throw exceptions: code that may signal errors with exceptions is pulled out of the constructor and encapsulated as a separate method. This is because try...catch blocks that include class instance declarations screw up otherwise clean block structures by preventing me from grouping all object instance declarations at the start of a block rather than sprinkling them through the code. Signaturemartin@ | Martin Gregorie gregorie. | Essex, UK org | Completely agree, Martin. "Goto" is quite nonsense - it's not needed from a theoretical as well as from a practical point of view. >> 1. The ability to share code between methods within a class, >> which all end with the same functionality (this could be more [quoted text clipped - 4 lines] > Encapsulating the code in a private method makes for more readable code > as well as eliminating code duplication. Plus, with modern JVM's the private method is typically inlined *if* it is a performance bottleneck. If not, it's not worth bothering about the method invocation overhead anyway. Side note: I am amazed that the "issue" of "goto" keeps popping up. The high time of Basic has long since gone but people still seem to cling to this ancient concept. Or do all these folks use assembler during their daily work? Regards robert > Completely agree, Martin. "Goto" is quite nonsense - it's not needed > from a theoretical as well as from a practical point of view. [quoted text clipped - 11 lines] > is a performance bottleneck. If not, it's not worth bothering about the > method invocation overhead anyway. That's a perfectly valid alternative for one particular application of "goto." > Side note: I am amazed that the "issue" of "goto" keeps popping up. The > high time of Basic has long since gone but people still seem to cling to > this ancient concept. Or do all these folks use assembler during their > daily work? This discussion is very interesting. One of the reasons I think "goto" keeps coming up is that there is demand for it. Although it is commonly associated with BASIC, it's also available in other languages such as Perl (which can be written in a procedural or OO style, or as mixture of both), assembler (the instruction is usually called "jmp"), etc. I'm not convinced that "goto" is a bad thing, especially given the numerous "while (true) { ... }" loops that I've seen over the years (granted, those are usually examples of bad coding style, but many people use it because they don't have "goto" at their disposal). To me, the limit on the placement of labels at the beginning of a loop, followed by a partial "goto" using the "break label;" instruction is actually more difficult to follow because first one has to find the label in preceeding code, then search for the end of the loop to follow the program flow from there. If the label could at least be placed anywhere from the beginning of the loop to immediately after its end, with "goto" enabled for this, I do think this could actually make things a bit better. I definitely don't agree that removing "goto" eliminates "spaghetti code" and works against the OO concept (as someone pointed out in a separate reply), rather it's the individual developers who will continue to write terrible code even without "goto" (which seems to happen now). As an aside, a much more serious problem is the lack of source code comments (usually the majority of the comments in source code are a copy of the GPL or some other license agreement -- the slightly better programmers include a minor smattering of vague hints in what seem to be fewer than one or two dozen randomly selected lines {out of thousands}). I do believe that a good developer can use "goto" in an intelligent way that doesn't result in "spaghetti code" and doesn't detract from the OO concept, so perhaps if Sun ever does decide to implement it they could also require a "javac" command-line option like "-allowadvancedinstructions:goto" as a hint that alternatives are strongly encouraged. The masses seem to be convinced that "goto" is bad, but in the history of the world there are countless examples where the masses were wrong (e.g., political elections, setting women on fire to determine if they were witches, removing tonsils because medical experts at the time believed them to be useless, mis-treatment of leppers, etc.). SignatureRandolf Richardson - kingpin+nntp@lumbercartel.ca The Lumber Cartel, local 42 (Canadian branch) http://www.lumbercartel.ca/ > This discussion is very interesting. One of the reasons I think > "goto" keeps coming up is that there is demand for it. I'm guessing that the demand is rather low - compared with the demand for other things (including fixing bugs). > I'm not convinced that "goto" is a bad thing, especially given the > numerous "while (true) { ... }" loops that I've seen over the years > (granted, those are usually examples of bad coding style, but many > people use it because they don't have "goto" at their disposal). An endless loop with "while(true)" is at least as good as a loop with "goto". > To me, the limit on the placement of labels at the beginning of a > loop, followed by a partial "goto" using the "break label;" instruction [quoted text clipped - 4 lines] > with "goto" enabled for this, I do think this could actually make things > a bit better. We must have very different coding styles. I cannot remember ever having used a label in Java. I simply don't need them. > I definitely don't agree that removing "goto" eliminates "spaghetti > code" and works against the OO concept (as someone pointed out in a > separate reply), rather it's the individual developers who will continue > to write terrible code even without "goto" (which seems to happen now). You are right. But this does not make an argument for introducing "goto" in Java. Only if benefits outweigh costs of this change it's reasonable to do it. And I don't see that. > The masses seem to be convinced that "goto" is bad, but in the > history of the world there are countless examples where the masses were > wrong (e.g., political elections, setting women on fire to determine if > they were witches, removing tonsils because medical experts at the time > believed them to be useless, mis-treatment of leppers, etc.). I won't follow this train of discussion as there are numerous things that could be said to this. Just this: if the majority of people do not care to have "goto" in Java then Sun's efforts are spent far better in realizing other features or fixing bugs. This alone is reason enough for not doing it IMHO. Regards robert > This is because try...catch blocks that include class > instance declarations screw up otherwise clean block structures by > preventing me from grouping all object instance declarations at the > start of a block rather than sprinkling them through the code. Personally I prefer to declare variables closest to the point of use, rather than all at the beginning of a block. - Lew >> This is because try...catch blocks that include class instance >> declarations screw up otherwise clean block structures by preventing [quoted text clipped - 3 lines] > Personally I prefer to declare variables closest to the point of use, > rather than all at the beginning of a block. Yes, I know your preference is normal and widely used. That was a personal opinion intended to show why I don't like constructors that throw exceptions. I've written far too much C (and Algol 60, Algol 68R, PL/9 and PL/1) to easily let go of the habit of declaring variables at the start of a block. If that makes me weird, so be it. Signaturemartin@ | Martin Gregorie gregorie. | Essex, UK org | > I've written far too much C (and Algol 60, Algol 68R, PL/9 and PL/1) > to easily let go of the habit of declaring variables at the start of > a block. If that makes me weird, so be it. I'm with you on this. I find that readability is improved if declarations are collected at the start of the method, rather than interspersed with code statements. While reading code, I think it's much easier to glance directly to the start of the method (which tends to stand out anyway) to see how a variable was declared, than to search upwards from the current position, looking for declarations in the code. Methods shouldn't be so long that the declarations end up "far" from first use anyway, or that the set of needed variables changes significantly thoughout the method. /gordon Signature[ don't email me support questions or followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e > I'm with you on this. I find that readability is improved if > declarations are collected at the start of the method, rather than > interspersed with code statements. I would accept your formatting in a code review if you said start of the block, rather than start of the method. Engineering rules trump formatting rules, so a "declare at the top" style should still yield to scope limitation. I distinguish between rules I follow and rules I want others to follow. I believe we all should limit the scope of variables, and I personally declare variables inline with use, but I wouldn't ask you to move your declarations in line. I happen to believe that readability is improved with variables declared near their use, diametrically opposite to your viewpoint. I also do not see any objective evidence that either of us is correct. I do see evidence that declaring variables in the narrowest scope provides stability and other engineering benefits. If I worked in a group that said "declare at the top of the block", I'd follow their rule except where engineering considerations override. - Lew >> I'm with you on this. I find that readability is improved if >> declarations are collected at the start of the method, rather than [quoted text clipped - 18 lines] > If I worked in a group that said "declare at the top of the block", I'd > follow their rule except where engineering considerations override. I'm happy with either approach and would go with either project standard without argument. I used to declare variables at the top of a block in the Algols and do like the scope limitation that provides: I guess that too much C has stopped me using it. I must try harder. The layout standard I've seen that I really don't like is the custom of declaring class-level variables after the methods. Why reverse the standard used inside blocks and methods other than sheer perversity? Signaturemartin@ | Martin Gregorie gregorie. | Essex, UK org | > The layout standard I've seen that I really don't like is the custom of > declaring class-level variables after the methods. Why reverse the > standard used inside blocks and methods other than sheer perversity? I used to do that; I have since reconsidered, but I can speak as a reformed sinner... I take it that you wouldn't want to see methods and fields interleaved (at least, not except in very special cases) ? If so then either the fields go first or they go last (or possibly both if you split public fields from other fields). Now it's also fairly normal to want to put public members before private ones[*]. So, fields, being private, don't go before the public methods... So they have to follow /all/ the methods. Simple! ([*] There's a well-regarded recommendation to do it the other way around for C++, but that is C++-specific -- and I can't remember the justification anyway.) -- chris >> The layout standard I've seen that I really don't like is the custom of >> declaring class-level variables after the methods. Why reverse the [quoted text clipped - 11 lines] > > So they have to follow /all/ the methods. Simple! The reasoning certainly makes sense. I tend to use the public/protected/private order, first for constants, then variables and finally for methods, so I suppose that's a semi-consistent way of doing it while still preserving the data declaration before code ordering. Signaturemartin@ | Martin Gregorie gregorie. | Essex, UK org | >>> I'm with you on this. I find that readability is improved if >>> declarations are collected at the start of the method, rather than >>> interspersed with code statements. Plus, and don't forget about this, otherwise you'll end up spending lifetimes to fix your program in case there is error. If variables are declared at the top of the methods, then all the error conditions and variable values could be seen if you set a breakpoint in correct place cause they won't go out of scope. Especially if you have the exceptions in that method, as if they are hit, you are COMPLETELY out to lunch, and it would take you lifetimes to figure out WHY that exception was hit if you are using declarations deep inside the method. I even avoid using things like for (int nInd = 0; nInd < limit; nInd++) Instead, i do int nInd; for (int nInd = 0; nInd < limit; nInd++) { ... } So, if i have an error condition inside for loop, i can see which exact element caused it, even if i am thrown out of the scope of the loop by some exception. >> I would accept your formatting in a code review I absolutly hate "code reviews". It simply means that there is some smart a.s, sitting on the top of a bunch of dummies, telling them how screwed up they are, and all it produces at the end is guilt, leading to fear to lose onse skin. Instead of those stupid "code reviews", you just work within a group and maintain a constant feedback and exchange the ideas. >> if you said start of the >> block, rather than start of the method. Engineering rules trump >> formatting rules, so a "declare at the top" style should still yield to >> scope limitation. I know plenty of those rules. But as far as end product goes, those "rules" do not cover about the most subtle issues, and especially the maintainability and future code modifications. Long subject. >> I distinguish between rules I follow and rules I want others to follow. I know, I know. :---} It is called scitsophrenia. In one situation you think like this, and in another situation you think like that. No wonder... >> I believe we all should limit the scope of variables, Yep. I like those "shoulds", the byproducts of a rigid mind. Now, on what basis should we limit the scope of variables? What does it improve? Not that I do not see what you mean, but you need to be able to put the WHOLE thing in perspective, and not only in terms of your ideology, but the debugging process, code extensibility, maintenance issues, code simplicity and readability and all sorts of other things. The rules of: THOU SHALT LIMIT THE SCOPE OF YOUR VARIABLES is simply incomplete of a statement. There are no ifs and buts in it. So, it is not programming. It is totalitarian dictatorship of black and white. Programming is a pure logic, as THAT is where all the intricacies come in. If you use this black and white model, your program will be the most oppressive thing there is. To the user, to the programmer and the rest of them mortals that come its way. >> and I personally >> declare variables inline with use, Uhu. And what happens if you hit an exception during debugging? Ever thought? Can you look at those variables inside some loop and see what EXACTLY happened? How long will it take you to fix bugs with this approach? How many times you would have to recompile and how many source files you'd have to go thru to see where is the error? You see, looking at the source is not the same thing as looking at the state of your program and variables in RUN time. Cause what you THOUGHT MUST be happening, for some strange reason, do not happen. And, usually, it is the simpliest things imaginable that break your royal code. >> but I wouldn't ask you to move your >> declarations in line. Which is about the most foolish thing to do. Just recently, i was lazy enoug to declare my variables in one lengthy operation where a number of files are opened and, in some cases, a single statement would cause the entire file load and parsing. The error would happen after tens of minutes of operation and, once the exception was hit, i did not have a SLIGHTEST clue what exactly was the reason for that exception. Once i moved the declaration on the most outside scope of method, i could see that error within seconds. Hows THAT for lesson in programming? >> I happen to believe that readability is improved with variables declared >> near their use, diametrically opposite to your viewpoint. It all depends. Sure, you are guaranteed a better memory dealocation and sure, you may avoid some subtle bugs if you initialize the variables on the most outside scope and, later on, use them when they were not properly set in the inner levels, and, instead of compile time errors, you get run time exceptions. No question about it. But this is just the BEGINNING of a story, and not the end. >>I also do not >> see any objective evidence that either of us is correct. Well, BOTH are correct and both are wrong. Because you need to specify ALL the conditions and ALL the tradeoffs. >> I do see >> evidence that declaring variables in the narrowest scope provides >> stability and other engineering benefits. To general to even consider. I doubt you have enough evidence for stability, and i do not even attempt to figure out what those "engineering benefits" are in specific terms. >> If I worked in a group that said "declare at the top of the block", I'd >> follow their rule except where engineering considerations override. "declare at the top of the block" dictates are no different then "use bracess this way" dictate. You can hit me with a sledge hammer, but i will still use the braces on the next line, and i have a REASON for it, you see, and the reason is simple enough to a mere mortal to comprehend. If you use braces at the end of a line, you can never be certain if you put them in the right scope, especially in nested "if else" clauses. >I'm happy with either approach and would go with either project standard >without argument. I used to declare variables at the top of a block in >the Algols and do like the scope limitation that provides: I guess that >too much C has stopped me using it. I must try harder. First of all, if you declare variables at the very beginning of you method, you can review that code and see if some variables and, therefore, some operations are simply overkill, or you are doing some extra work on a method level that would not have to be done if your code was more structured. So, by sheer fact that you have some variables, it indicates that you do some operations that NEED those variables, and you can see that you might be using several variable to carry the same exact information except in a slightly different context, and so you can fix that code. As far as memory management goes, it is true that the memory deallocation may improve if you declare those variables on the deepest scope possible as in that case, the deallocation is pretty much automatic. But again, that is just a beginning of the story, and not the end. >The layout standard I've seen that I really don't like is the custom of >declaring class-level variables after the methods. Why reverse the >standard used inside blocks and methods other than sheer perversity? Well, i must be a pervert then. I agree with you that it is better to move it in front, generally speaking, but some methods have so much stuff attached to them that it takes you quite some time before you see the constructor code, which is about the FIRST thing i want to see. Then, after contructor code, i like to put the highest, possibly thread level methods, such as start, stop, run, Terminator (ever heard of such an animal), and things like that. Then, I'd like to see the main method, starting the whole operation. Then, after it, i like to see the more fine grained methods. And, about the LAST thing i want to see, is the even handler code. That comes as just about the LAST thing in that class, and the beauty of it, i know EXACTLY where i can find it, even if i do not remember the exact name of some variable or method, which is an art on its own. I can remember just about every single method or variable in a pretty complex program, just because of naming convention i use. I can see what the methods do simply by looking at the variable names those methods use. And, the LAST thing i want to see is... Tada! The VARIABLES, in bulk. But even there, they are all nicely sequenced and the first in order come those of the most outer scope and meaning, the MAJOR variables, that could correspond to entire complex classes, frames, etc. Then comes the file level variables, file names, handles, etc. Then come the groups of related variables describing some logically related operations or constructions. Then comes the miscellaneous stuff, which i periodically look at to see what kind of garbage is there as there should be none on the first place as just about all the variables should be decleared on more local scope, otherwise you have a database consistency issue, when several different methods access the same global, and, in some cases, one hand does not know what the other is doing. As a general rule, I use as little globals as I can manage. So far, my stuff runs, compiles, extends, and maintains like a tank. Try to kill it. Even if you unplug the power cord, in the middle of a file operation, I'll recover, as long as operating system can recover the damaged file. :--} >>>> I'm with you on this. I find that readability is improved if >>>> declarations are collected at the start of the method, rather than [quoted text clipped - 8 lines] > could be seen if you set a breakpoint in correct place > cause they won't go out of scope. If your methods are /so/ big that this presents a problem to you then I respectfully suggest that your methods are /too/ big; making them smaller will simplify your [1] scope issue and allow you to give useful names (and a respectable meaning) to the segments you extract as well as making your names properly local. [1] I've had an issue with very-local-scoping perhaps once in the past twenty years; that was in C. I spotted it the next time I ran my ad-hoc tests and fixed the issue in about twenty seconds. Of course anecdotes are not data. SignatureChris "electric hedgehog" Dollin There' no hortage of vowel on Uenet. >>>>> I'm with you on this. I find that readability is improved if >>>>> declarations are collected at the start of the method, rather than [quoted text clipped - 14 lines] >that your methods are /too/ big; >making them smaller Agreed. But, in case of code I am dealing with, it is easier said then done. I did try get get rid of as much stuff, as I could manage, but there are some more subtle issues involved. ANY class is guaranteed to be aware of the main class and so it can ask from main just about any information out there. But if your move some code to their own classes, you simply add at least one more level of idirection and a number of get/put methods. Sure, we can argue about it this way or that, and if i wrote this code from scratch, i'd probably use the entirely different approach and use state machine an fully asynchronous operation. Unfortunately, to rewrite the code to do that is just about as good as scrapping the whole thing and starting from scratch. Too much work to be done and too lil time to do it. >will simplify your [1] scope issue >and allow you to give useful names >(and a respectable meaning) >to the segments you extract >as well as >making your names properly local. Agreed. >[1] I've had an issue with very-local-scoping > perhaps once in the past twenty years; [quoted text clipped - 7 lines] > Of course anecdotes > are not data. Yep, and I know EXACTLY what I am talking about. Played with this scope thing in just about any way imaginable. In some simpliest cases i do use the most local scope possible, usually at the point of initial prototyping. But then I look at the code and try to move all declarations as high up as I can manage because I know all too well, that when I have some bug and a breakpoint hit or exception triggered, about the last thing i want to see is my variables getting out of scope. > Yep, and I know EXACTLY what I am talking about. > Played with this scope thing in just about [quoted text clipped - 6 lines] > triggered, about the last thing i want to see > is my variables getting out of scope. Or lingering past their useful scope and causing trouble thereby. - Lew Lew wrote: >>> I distinguish between rules I follow and rules I want others to follow. > I know, I know. > [quoted text clipped - 3 lines] > In one situation you think like this, > and in another situation you think like that. The correct spelling is "schizophrenia" and it refers to a psychosis whereby the patient suffers hallucinations, delusions, inappropriate affect or other symptoms of being completely out of touch with reality. You may be referring to so-called "split personality", which is not schizophrenia but a completely different disorder. <http://en.wikipedia.org/wiki/Schizophrenia> A stereotypic type of schizophrenia is paranoid schizophrenia, wherein the sufferer imagines themself the object of persecution, ridicule, oppression or other hostile behavior when no such behavior actually exists. Lew said: >>> and I personally >>> >> declare variables inline with use, > Uhu. > > And what happens if you hit an exception > during debugging? > > Ever thought? Of course. > Can you look at those variables inside some loop > and see what EXACTLY happened? Yes. > How long will it take you to fix bugs with this approach? Not too long. > How many times you would have to recompile > and how many source files you'd have to go thru > to see where is the error? Once, after I fix the bug. > You see, looking at the source is not the same thing > as looking at the state of your program and variables [quoted text clipped - 3 lines] > And, usually, it is the simpliest things imaginable > that break your royal code. That is why I use exception handling, logging and debuggers. Lew said: >>> I believe we all should limit the scope of variables, > Yep. I like those "shoulds", > the byproducts of a rigid mind. Or of one that has read Joshua Bloch on this subject (/Effective Java/) and others, and has understood the benefits of the approach. The /ad hominem/ attack does not go far to support the argument. - Lew > If variables are declared at the top of the methods, > then all the error conditions and variable values > could be seen if you set a breakpoint in correct place > cause they won't go out of scope. Fair point. > I absolutly hate "code reviews". > It simply means that there is some smart a.s, [quoted text clipped - 3 lines] > is guilt, leading to fear > to lose onse skin. I don't like them either, but some organizations like them, especially when they have a high proportion of new grads to knock out the code. My worst case: the project's Technical Manager defined the coding standards - basically standard K&R layout and naming conventions (it was an ANSI C project) - and then went on holiday. Meanwhile I'd finished detailed design and three of us had written and tested the project's specialized function library, which included an in-memory active data dictionary. At this point the Tech Manager returned from holiday and re-issued the coding standards. Somebody must have dropped him on his head while he was away because he now mandated Hungarian Notation (Microsoft's poison gift to the world). I hit the roof because we had no time or resource to rewrite the library code. The Project Manager should have canned the new standard, but instead said we were both right. The end result was that everybody else wrote horrible hungarianised code while I and the other technical designers wrote to K&R standards. The moral of this is: NO radical changes to project standards once they've been issued. EVER. In fact we didn't use code reviews on that project despite having a large grad coding population, but we did require them to write module specs in pseudo code and we reviewed that to make sure they had understood the tech spec. That worked well and the end result, a large, scalable multi-process system had no gross functionality, control or interfacing problems. > Then, after contructor code, i like to put the highest, > possibly thread level methods, such as start, stop, run, > Terminator (ever heard of such an animal), and things > like that. I put main() (if there is one) first, but if there's a main() the probably are no constructors. Then I put public methods followed by protected and private methods. Within each group of methods they're simply in alphabetic order for ease of reference within the source file. Signaturemartin@ | Martin Gregorie gregorie. | Essex, UK org | >> If variables are declared at the top of the methods, >> then all the error conditions and variable values [quoted text clipped - 47 lines] >protected and private methods. Within each group of methods they're >simply in alphabetic order for ease of reference within the source file. Alphabetic order? Never heard of such an animal. I use cut'n'paste style of programming if you ever heard. :--} So, when I look at some code and, all of a sudden, realize it could be done better by moving some of it to a dedicated method, I simply make up a name of method, put a call to it just where the old code was, copy that call and insert it at the top of old code, and then cut a bunch of old code out and paste it just before the old method. The next thing i do is to try to compile and it shows me all the variables that are missing. Zo... We just cut and paste those from the old code to the very top of new method. If the old method conc out because now it does not have its old variables, we look at that animal and see where critical points are, and so it weiks like a champ. Just a couple of minutes and you have a brand new method that could be used by other boogers cause that is the whole point of it, to make it more universal and more structured. But ALPHABETICAL sorting? Maaaaan. You can get into the Guiness book of werld records fer dat! good luck. > > This typically occurs because the reserved word "goto" isn't > > implemented. There are situations where "goto" would be very useful, > > such as: > > I totally disagree. Assemblers need "goto" but no decent HLL does. That > goes for COBOL too and before you ask, yes I've written GOTO-less COBOL. Huh! I coded COBOL as well, and was not even aware it *had* a GOTO. (Seems I never saw the need to RTFM that far - even though it was my 'instruction manual' for the language.) Andrew T. >>> This typically occurs because the reserved word "goto" isn't >>> implemented. There are situations where "goto" would be very useful, [quoted text clipped - 6 lines] > saw the need to RTFM that far - even though > it was my 'instruction manual' for the language.) Post-1985, then, I imagine. Until then, it was possible to manhandle a COBOL program into GOTO-less form, but it tended to be fragile. SignatureJohn W. Kennedy "The blind rulers of Logres Nourished the land on a fallacy of rational virtue." -- Charles Williams. "Taliessin through Logres: Prelude" >>>> This typically occurs because the reserved word "goto" isn't >>>> implemented. There are situations where "goto" would be very useful, [quoted text clipped - 9 lines] > Post-1985, then, I imagine. Until then, it was possible to manhandle a > COBOL program into GOTO-less form, but it tended to be fragile. Indeed - and I wrote mostly COBOL and assembler before 1985 and mostly other languages (C, Tal, PL/1) since. I suspect my COBOL habits are permanently set by that experience. The problem with goto-less COBOL was that not all conditional clauses could have ELSE clauses. These implied conditionals were mandatory parts part of some verbs, such as READ.....AT END.... COBOL-85 introduced ELSE clauses to the implied conditionals and in-line PERFORM clauses, so now its easy to write: PERFORM READ A-FILE AT END MOVE "YES" TO A_FILE_EOF ELSE NOTE Process the record END-IF WHILE A-FILE-EOF NOT = "YES". Prior to COBOL-85 writing it as goto-less code used to look like this: PERFORM READ-INPUT-FILE WHILE A-FILE-EOF NOT = "YES". ... READ-INPUT-FILE SECTION. RIF-1. READ A-FILE AT END MOVE "YES" TO A-FILE-EOF. IF A-FILE-EOF NOT = "YES" NOTE Process the record. RIF-EXIT. EXIT. and arguably AT END MOVE 'YES' TO A-FILE-EOF GOTO RIF-EXIT would have been a more robust solution than using the extra IF statement. ...and that's quite enough COBOL in a Java group. I now return you to the normal language. I thank you for your time. Signaturemartin@ | Martin Gregorie gregorie. | Essex, UK org | >>>>> This typically occurs because the reserved word "goto" isn't >>>>> implemented. There are situations where "goto" would be very useful, [quoted text clipped - 47 lines] > and arguably AT END MOVE 'YES' TO A-FILE-EOF GOTO RIF-EXIT would have been > a more robust solution than using the extra IF statement. What about: PERFORM READ A-FILE AT END MOVE "YES" TO A_FILE_EOF NOT AT END NOTE Process the record END READ WHILE A-FILE-EOF NOT = "YES". ? I'm not sure how "standard" this is, but I believe this works on both Liant RM/COBOL and ILE COBOL400. - Oliver >>>>>> This typically occurs because the reserved word "goto" isn't >>>>>> implemented. There are situations where "goto" would be very useful, [quoted text clipped - 61 lines] > I'm not sure how "standard" this is, but I believe this works on both Liant > RM/COBOL and ILE COBOL400. NOT AT END is certainly not standard pre-1985 COBOL. SignatureJohn W. Kennedy "The blind rulers of Logres Nourished the land on a fallacy of rational virtue." -- Charles Williams. "Taliessin through Logres: Prelude" > What about: > [quoted text clipped - 6 lines] > END READ > WHILE A-FILE-EOF NOT = "YES". That's essentially my first example give or take a few reserved words which I could well have got wrong: I haven't written any COBOL (apart from the wildly deviant Tandem Screen COBOL) for over 10 years, and on that project most of my input was in C (a conversion process to map SNA LU6 sessions onto TCP/IP sessions in case you wanted to know). Signaturemartin@ | Martin Gregorie gregorie. | Essex, UK org | > [sNip] >>> while (true) { [quoted text clipped - 14 lines] > attempts to access variables that belong to different methods, return > type mismatches, etc.) I disagree, I think goto was dumped for very good reasons, and structured programming (i.e. no gotos; use methods and refactoring techniques instead) makes a lot more sense. > I do agree with your view that infinite loops that depend on > exceptions are a bad practice. Using conditionals to trigger a "break" [quoted text clipped - 5 lines] > The Lumber Cartel, local 42 (Canadian branch) > http://www.lumbercartel.ca/ > I disagree, I think goto was dumped for very good reasons, and > structured programming (i.e. no gotos; use methods and refactoring > techniques instead) makes a lot more sense. I suspect that Java left in "goto" as a reserved word for the same reason that Ada supports (with intentionally hideous syntax) "goto" -- considerations of machine-generated code. But jumping from one method to another? Ye gods! Even Fortran doesn't allow that, except for a jump-out-to-caller mechanism that is essentially a poor-man's "throw". SignatureJohn W. Kennedy "The blind rulers of Logres Nourished the land on a fallacy of rational virtue." -- Charles Williams. "Taliessin through Logres: Prelude" >> I disagree, I think goto was dumped for very good reasons, and >> structured programming (i.e. no gotos; use methods and refactoring [quoted text clipped - 7 lines] > allow that, except for a jump-out-to-caller mechanism that is > essentially a poor-man's "throw". What exactly are you talking about when you refer to jumping from one method to another? Which language, which construct? lex >>>I disagree, I think goto was dumped for very good reasons, and >>>structured programming (i.e. no gotos; use methods and refactoring [quoted text clipped - 11 lines] > method to another? Which language, which construct? > lex Fortran has a construct called "alternate return" that lets the callee pick from caller labels supplied as call arguments. I have only ever seen it in Fortran compiler test programs. Patrica >>> I disagree, I think goto was dumped for very good reasons, and >>> structured programming (i.e. no gotos; use methods and refactoring [quoted text clipped - 9 lines] > What exactly are you talking about when you refer to jumping from one > method to another? Which language, which construct? The hypothetical "improved" (ick! gack!) Java that this thread is talking about. But some older languages do have the ability to goto (permanently) out of a routine to a statement in its caller (or caller's caller, etc.). As I said, that is essentially a poor-man's "throw". SignatureJohn W. Kennedy "The blind rulers of Logres Nourished the land on a fallacy of rational virtue." -- Charles Williams. "Taliessin through Logres: Prelude" >>>> I disagree, I think goto was dumped for very good reasons, and >>>> structured programming (i.e. no gotos; use methods and refactoring [quoted text clipped - 16 lines] > a routine to a statement in its caller (or caller's caller, etc.). As I > said, that is essentially a poor-man's "throw". You'd need to clean up the call stack (assuming you were using one at all . . . LOL!!!) Myself, originally a GW-BASIC programmer, have used goto extensively in my life - and see absolutely no benefit to using it. If your program requires truly unusual code flow it can be accomplished with try catch blocks. I can't believe this thread is still alive. I will admit I used goto once in C++ just to be a rebel (certainly not because I needed one). Then I replaced it with an if statement. -- LTP :) >>>>> I disagree, I think goto was dumped for very good reasons, and >>>>> structured programming (i.e. no gotos; use methods and refactoring [quoted text clipped - 17 lines] > You'd need to clean up the call stack (assuming you were using one at all . > .. . LOL!!!) Any language that can do calls uses some kind of call stack, even if it's only a chain of staticly-stored return addresses. But, yes, you have to clean it up. > I will admit I used goto once in C++ just to be a rebel (certainly not > because I needed one). Then I replaced it with an if statement. Goto is good for getting out of a nested loop if you don't have the equivalent of a Java labeled break. And it can give better performance in nasty machine-generated decision-table or state-machine code--but I wouldn't use it in hand-written code. SignatureJohn W. Kennedy "The blind rulers of Logres Nourished the land on a fallacy of rational virtue." -- Charles Williams. "Taliessin through Logres: Prelude" > This typically occurs because the reserved word "goto" isn't > implemented. There are situations where "goto" would be very useful, such > as: > > 0. An alternative to "break label" since label is currently limited in > where it can be located (such code could be easier to read) I'm not in the "GOTO is intrinsically evil" camp -- I think it has its uses, and (if used with discretion, which is the only way that anyone /does/ use goto these days), can help keep code clean. Mind you, a lot of the reasonable uses for goto are replaced in Java by try/finally statements; so I'm not sure that it would actually pay for itself. But the labelled-break thing is, IMO, even worse than goto could possibly be -- it always seems to make the code confusing. Fortunately, it is hardly ever used. To be honest, I don't know whether the few times I /have/ seen it used are confusing because the programmer (having labelled break available) didn't feel the need to find a clearer structure, or because the underlying task logic itself was inherently confusing, and a labelled break was the best available way to express it. > 1. The ability to share code between methods within a class, which all > end with the same functionality (this could be more efficient than calling > another method; javac would need to generate errors such as attempts to > access variables that belong to different methods, return type mismatches, > etc.) I think that's technically infeasible given anything like current JVM implementation technologies. -- chris >> while (true) { > > To depend on exceptions as flow control is a bad practice. That may be, but he hasn't done so in this case. The loop condition here is (curline != null), even though the test doesn't occur until a few lines further down. BTW exceptions *are* a form of flow control, whether you like them or not. /gordon Signature[ don't email me support questions or followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e Gordon Beaton schrieb: >>> while (true) { >> To depend on exceptions as flow control is a bad practice. ... > BTW exceptions *are* a form of flow control, whether you like them or > not. That may be but he didn't tell us if they are or are not a form of control flow. To my understanding the key was not to *depend* on exceptions as flow control or IOW not to (mis)use the exceptional flow to control the main flow which is right although not always possible. Bye Michael On Jan 31, 5:11 pm, "Lab.Bhattachar...@gmail.com" <Lab.Bhattachar...@gmail.com> wrote: > Hi kavitha, > u can try out the following code , it allows wild cards ,but is case [quoted text clipped - 53 lines] > thanks > lab hi thanks for ur reply. it will also be helpful if u sent the coding which u have asked me . waiting for ur reply regards D.kavitha > thanks for ur reply. it will also be helpful if u sent the coding > which u have asked me . Juat a word of friendly advice: Your posts will seem much more professional, and you will be in better practice for workplace communication, if you make a habit of using more (not completely) formal written English, in particular if you avoid so-called "l33t-speak" or "txt-English", comprising abbreviations like "u" for "you", informal or missing punctuation and capitalization, etc. The trouble is that the use of the abbreviated idiom conveys an impression of unprofessionalism and a low skill set. This may be the view of yourself that you wish to convey, but I fail to see how that can help you. You will impress more, and likely get more expert responses, if you take the care and trouble to follow conventional English syntax and orthography (barring the odd misplet word - this forum isn't completely formal). Just a suggestion designed to help you. - Lew > Just a suggestion designed to help you. Adding to that: a meaningful subject also often helps. :-) Cheers robert >i want to search a particular word in the file using java. > can u give any specific link for this http://www.google.ca/search?q=search+a+particular+word+in+the+file+using+java - Oliver Hi.. Kavitha how r u, i hope u got the answer for u r question >From u r Friend Rocky Take Care Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.