|
|
If a persion gives wrong statement against a good answer how can provide down points
|
|
|
|
|
Do not worry about points. They do not mean anything.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Thank you for your comment as well as you others are also started like you
|
|
|
|
|
I am trying to browse through my articles submitted sometime back. However I am getting message as - This article is still being written and is not currently available for general viewing.
Can anyone help me how to recover my submitted articles.
Thanks
Kishan
|
|
|
|
|
Have you published the article? What I think of this is that you have not yet published the article and are currently viewing the draft.
Secondly, if you have published it, and still see it: It might be because you have tried to modify it sometime in past, and you are being previewed the latest draft. To check if that is the case, go to "My Articles" and see the Drafts. You will find it there, also, if you published the article, the older version will still be visible to general public.
For future posts about Article Writing, try contacting the admins here, Article Writing Discussion Boards
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Should I have to begin with replacing ASCII with something new like Indian Standard Code for Information Interchange? Please give tips.
|
|
|
|
|
|
Thank You for this 
Would it help in building Internet in Hindi as Chinese and Japanese did in their respective languages?
|
|
|
|
|
|
Sorry, I've no idea of Ruby.
There used to be video games and cartridges with text written in Japanese/Chinese languages.
Have you ever wondered if there were Hindi characters from the beginning instead of English characters in programming and all over the web? I'm asking this.
It might be like 'Reinventing the wheel'. Getting to origin from where these English knowing people started.
If I learn the basic of programming development, then I can create programs independent of regional languages present on earth. Then requirement of knowing English would not be necessary.
|
|
|
|
|
True, as programming itself is a language but I do believe some parts of it would be required in native tongue or in english to execute properly.
You can also try this as well:
Vistalizator - change display language in Windows Vista and Windows 7[^]
This is a language pack for Windows Operating Systems and is 100% safe (I've used it on multiple occassions for JROM's and the like, as they would NOT run if they detected an english OS machine). Have you tried going to the actual Hindi sites? Sometimes languages will have notepads in that specific language (such as Sakura Notepad for JP).
|
|
|
|
|
|
Our company have been outsourcing development of several business systems for a number of years, with various software houses/vendors, and have been surprised that many do not come with a predefined "SDLC package", but rather expect us to tell them how to work. Despite instructions being given, we've also had a few issues with them following processes; e.g.
- After one vendor left the project we tried to work with the projects they'd left behind only to find a number of items only partially checked in (i.e. some developers were clearly checking things in, others just working on their local copy and only selectively checking in a subset of the files required for the solution to work).
- With a vendor we're currently working with, we ran an audit only to find they'd stopped checking in code a year previously after their firewall blocked their access to VSTS; so they just stopped using it without telling anyone, rather than fixing the issue or even informing us of a problem. We told them how to fix that issue, but since then every issue they've had they've come to us for support rather than resolving their own issues. NB: These issues are with standard products / their set up; the only thing we control is their permissions within VSTS, which are all correct.
We've had other similar issues, but these 2 were the major WTF moments (the software houses we're dealing with are multi-national companies supporting a variety of products, including all of those they're developing for / involved in our SDLC lifecycle).
Questions:
- Is our experience common; i.e. not being able to trust a software vendor to adhere to basic SDLC practices / having to put considerable effort into supporting & auditing them?
- Are there ways of working to help ensure that you manage your vendor correctly / get them to provide you with a quality service without having to manage & support each member of their team directly?
- Are there any resources for comparing the quality of service customers can expect from different vendors?
NB: I'm deliberately keeping company names out of this as feel that may be inappropriate / our experiences may not be representative.
|
|
|
|
|
Option Tag width not working in Chorme.
|
|
|
|
|
- You're in the wrong forum. Post your question in the Web Development forum[^].
- You're going to need to provide significantly more information that that if you expect anyone to be able to help you.
- Create a minimal reproduction of the problem in JSFiddle[^] and post the link to it.
- Tell us what version of Chrome you're using.
- Include the full details of any errors.
- Tell us what you've done to try to solve the problem.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Evening folks,
Not sure which board this question/rant belongs so I am just going to put it on here.
I would love to know how people generally feel about comments in code as a means to describe what the code does. In my workplace that I only started at about 2 months ago, I have already had about half a dozen discussions about why I think code comments are a) largely a waste of time b) distraction from writing the actual code c) give license to a developer to be sloppy with their code.
Kevlin Henney's talk on this subject is pretty much along the same lines but there must be some bigger picture that I must be missing that my colleagues in office know that they are forcing me write comments in code. I have been developing software for about 11 years professionally and 15 years if you include the pizza and soda filled days of academia and I have transitioned from code commenter to just writing clean enough code that tells the reader what it does (thanks to Uncle Bob!!) so I find it incredibly backward having to go back to writing comments just to save my job.
I do understand in some cases comments might be necessary where the code intrinsically is complex and cannot be refactored any more but putting documenting comments on every class, function and property just for the sake of it seems ridiculous. I also understand publicly consumed APIs need to have documentation so client developers can build apps on top of them but anything beyond these 2 use cases, is stupid IMHO.
Thoughts, outrages, feelings?
Cheers
IEC
|
|
|
|
|
I've been writing software for almost 40 years, and I'll take your bait. 
As is the case with almost every engineering issue, there is a fine line between appropriately commenting code and commenting just to fill a space. To that end, I think you are partially correct, but I think we differ in three key respects, unless I misunderstood you.
- Every function or method should be prefaced with a short explanation of the algorithm that it implements or the task that it performs. Obviously, if the function is part of the public interface, this comment should take the form of an XML comment, which need not be repeated as a regular comment. You can also make a good case for attaching XML comments to every method. Indeed, I usually follow this practice in my own work, and I've seen it often in the work of others.
- Every class must begin with a short explanatory comment about its purpose. As is the case with methods, this can take the form of XML commenting.
- Every module must contain a change log, and you must be fastidious about adding a note, brief though it may be, every time you change it.
With respect to the third point, some would argue that this is the purpose of check-in comments, but my experience has been that these are almost invariably insufficient to properly document what changed, and why a file was included in a given changeset. I have wasted many valuable hours, usually aided by side by side changeset comparisons, to obtain such knowledge, which would be ridiculously easy to put into a change log. In my view, the changeset log is just not sufficiently granular to be your whole change history.
Finally, in the first point, I mentioned attaching XML comments to all methods. The benefits of doing so are twofold.
1 Since IntelliSense picks up local XML comments, it's easier to consume provate methods in other parts of the same project.
2 If you decide later to make a class or method public, the XML comments are already there, so the only required change is to the access modifier.
While I agree with you that commenting can be used to compensate for sloppy code, there are some things that just cannot be documented by the code alone.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
Yeah I was referring to the XML comments and specifically in C# and I appreciate your point that not everything can be communicated by the code sufficiently clearly for e.g. a complex algorithm implementation that might require some additional prose to describe the whats, the whys and the hows. Perfectly acceptable.
However, I don't agree with putting even XML comments everywhere even when the code is self-evident. If I as a developer don't write clean enough code that reveals its intentions and purposes then how can I be relied upon to write clear concise comments? At best/worst I might be lying about the code which probably will become clear in code reviews but code reviews are about the code, not comments. Code executes, comments don't. If I am going to spend effort anyway, I'd rather use it to refactor code, not comments. Not to mention maintaining code itself is a major task add to that the burden of maintaining the comments and the whole thing becomes a real drag on programmer productivity. I much rather spend that time on refactoring and testing the code to make it as clear and provable as possible.
Plus, compiler provides little to no support for comments (apart from cosmetic colour coding) and any time I change a method signature or the purpose, comments don't auto update because they can't read my mind! Now, office politics perhaps may be a reason why someone might get forced to write comments despite their better judgement, which I think might be at play in my case.
On the change log, I believe check-in comments are the place to put your reasoning to have changed any code. This way I can look at the comments in source control and if I feel like I can just do a diff to see what changed and whether or not it correlates to the comment. Ultimately, its about the developer discipline and I much rather use it to write meaningful and clean code, test cases and check-in comments rather than bunging everything in the source code file that contains everything but meaningful code. Its like my grandma used to say, "Everything in its place and a place for everything!".
Thanks for your input anyway. Appreciated! 
|
|
|
|
|
Well, then, your check-in comments must be books. Most of the ones I've seen, and even written, are no more than a paragraph.
Furthermore, if I put everything in the check-in comments, than I have to keep a Team Explorer window open to see them. If it's related directly to Module A, then it belongs in Module A.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
You don't actually have to document every single line of code that you change (unless you were writing software for safety critical systems), if you follow "Check-in early, Check-in Often" then you're only describing the change as succinctly as possible with each check-in as your changeset is likely to be relatively small. Things tend to get messy if you are into big shot releases where changes have been building up for weeks on end if not months, in that case of course you would lose the track of what has changed and why.
The worst I have seen so far in my experience is someone, and at times me too, had to put in 2-3 mini-bullet points to describe the change at a logical level. But change logs in source files is an old fashioned concept and I haven't really seen it in the places I have worked in so far so I am not going to worry about that as much. My main gripe is with source code comments.
|
|
|
|
|
IMO, old-fashioned != outdated.
As an example, last year, I had a changeset that included models, views, and controllers for two entities. A few weeks later, when I reviewed the code for another use story, I found myself scratching my head about why the view, which shouldn't have been affected by the changes to implement the last user story that touched these modules. I eventually figured out why it got in there, but I wasted a good deal of time on it that could have been put to better use working on another user story.
Histories were banned at the last two places that I worked. Instead, programmers were urged to enter dated comments adjacent to code changes. While this is nice, and I do that, you can't find them without searching the file for a date, and praying that everyone writes theirs in the same format. A history at the top of the source file is easy to maintain, and is discarded by the compiler, so has no effect on the generated machine code or byte code.
When I review source code that has a history, I can frequently confine my examination of a particular file to its history, because I can learn everything I need to know about it from the last entry or two. Working on a complex application that has many moving parts, changeset notes just aren't enough. Besides, they are not written until after the change is made and tested, when it's harder to remember why you changed each file in the set.
From time to time, I've brought some of my own code into a project, and when I've done so, the history stayed with it.
I wrote my first "real" program in 1978, and everything that I just said is the result of almost 40 years of hard won lessons, some learned when I stopped doing something that I thought was unnecessary, or had been superseded by some newer method that was allegedly better. I can't count the times that I've had to revert to my "old" way of doing things, because the "new" way was just too unproductive. Histories in source code belongs on that list.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
To each their own, I guess! I prefer to put these kinds of comments while checking-in/pushing my work to the source control. I don't like the source file bloat irrespective of whether or not you can collapse such sections. With the use of labeling, tagging and linking the changeset with the user story right from within Visual Studio (at least) I personally don't feel there is any extra wastage of time if you need to know why something was changed.
Usually for these kinds of comments I am only describing the reason for change at a high level may be in the language of the acceptance criteria described in the backlog which keeps things nice and clear. For everything else, one can read the code.
|
|
|
|
|
Personally, I try to use *doc* style (Javadoc, Doxygen, Pydoc). For C/C++ only in the header files. However, I only comment the stuff I think is helpful to maintain the code. Most developers forget to modify existing code comments, so there's no need to be pedantic and comment about what is clearly gleaned from the source![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif) .
|
|
|
|
|
I am going to have side with David (@Enigmatic-Texan) on this one. If you rely on code documentation tools, such as SandCastle, the inclusion of XML comments on all public methods and properties is a must. Also, I also agree with your statement that if the code is complex and hard to decipher than comments walking someone through it is a must. Even I have written code that, when re-visited, elicits a  response. Comments for the sake of comments could be considered a waste of time. Heck, I usually don't comment my code until it's time to start building the documentation.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
