I have noticed that commented lines in Scenario Outline do not appear in the HTML report steps even though this is not the case for regular Scenarios.
By any chance, is this intended or is it an overlooked bug?
I am aware that this issue is very minor and low in priority but it is helpful for cases like mine, whose lines of code can get a bit long. In-line comments help in documenting and separating blocks of code in my test scenarios.
Thanks in advance!
May be overlooked. This is certainly not a priority for the project developers, you are welcome to contribute code.
Custom reports can be easy if you know Java, refer: https://stackoverflow.com/a/66773839/143475
EDIT - at the very least, please submit a simple sample so that the problem is clear, following the instructions here: https://github.com/intuit/karate/wiki/How-to-Submit-an-Issue
i'm getting started with sitecore and i just discovered this tool sitecore offers to test our queries:
My problem is i just can't make it return results and i do know this query works perfectly cause i've been using it on my project right now.
There is probably a problem of syntax somwhere i don't know.
Thank you for helping me to put some light on this !
It's a bit difficult to tell due to how bits of that are redacted (there might be other syntax errors hiding under the boxes), but there's one obvious issue there, I think: You don't need the "query:" bit on the beginning of what you've typed.
In general, if the API or web form your filling in can only take a query expression you can leave the "query:" bit off. But if you're putting text into somewhere that might take a query or might take something else then "query:" is needed to tell Sitecore what it's looking at.
Some lines of codes don't need to be checked by Sonar (Sonarqube.org). How can I just disable checking on these lines? Is there any way like just addding annotation "#" to make these lines invisible for Sonar? Thank you!
There are several ways. See FrequentlyAskedQuestions-NOSONAR and further down that page to see both a comment (//NOSONAR) and annotation (#SuppressWarnings) options, as well as some other ways to disable checking.
From official docs:
How do I get rid of issues that are False-Positives?
False-Positive and Won't Fix You can mark individual issues False Positive or Won't Fix through the issues interface. If you're using
Short-lived branch and PR analysis provided by the Developer Edition,
issues marked False Positive or Won't Fix will retain that status
after merge. This is the preferred approach.
//NOSONAR Most language analyzers support the use of the generic mechanism: //NOSONAR at the end of the line of the issue. This will
suppress the all issues - now and in the future - that might be raised
on the line.
So I am not very good with computers and have to create my first app for a project. It's going fine so far - essentially I am trying to create an app that records and saves data. Right now I'm still getting the record part down, since Xcode is having periodic issues. I am using this link for setting up the code:
http://www.techotopia.com/index.php/Recording_Audio_on_iOS_7_with_AVAudioRecorder
Unfortunately, I am running into 2 types of semantic errors, two red, two yellow. They are all in RecordModelController.m - the first is like this:
return [self.pageData indexOfObject:viewController.dataObject];
Xcode claims that Property 'dataObject' isn't found in any object or forward class in 'RecordDataViewController'. That's actually my two red errors, they just sound very similar so I paraphrased them into one. The yellow error, however, repeats itself twice on the same line of code, which is:
return [self viewControllerAtIndex:index storyboard:viewController. storyboard];
The yellow issues on these lines of code (again, repeated twice) is "Incompatible pointer types returning 'RecordDataViewController *' from a function with result type 'UIViewController *'" - I genuinely tried to look in RecordDataViewController.h and couldn't make sense of this. Like I said, bad with computers, not sure why I'm having this issue, and I know that it's probably something basic.
If anyone would be willing to help me out with how to deal with issues like this, that would be great. Thanks, and sorry for my incompetence.
The red are called errors. The yellow are called warnings. I'm going to suggest you look at a few beginning Xcode/iOS programming tutorials so you understand the basic concepts of how view controllers, arrays, etc. work in objective-c. The best place to start for someone completely new as yourself is here: http://www.raywenderlich.com/tutorials
Hope this helps!
Some of my colleagues use special comments on their bug fixes, for example:
// 2008-09-23 John Doe - bug 12345
// <short description>
Does this make sense?
Do you comment bug fixes in a special way?
Please let me know.
I don't put in comments like that, the source control system already maintains that history and I am already able to log the history of a file.
I do put in comments that describe why something non-obvious is being done though. So if the bug fix makes the code less predictable and clear, then I explain why.
Over time these can accumulate and add clutter. It's better to make the code clear, add any comments for related gotchas that may not be obvious and keep the bug detail in the tracking system and repository.
I tend not to comment in the actual source because it can be difficult to keep up to date.
However I do put linking comments in my source control log and issue tracker. e.g. I might do something like this in Perforce:
[Bug-Id] Problem with xyz dialog.
Moved sizing code to abc and now
initialise later.
Then in my issue tracker I will do something like:
Fixed in changelist 1234.
Moved sizing code to abc and now
initialise later.
Because then a good historic marker is left. Also it makes it easy if you want to know why a particular line of code is a certain way, you can just look at the file history. Once you've found the line of code, you can read my commit comment and clearly see which bug it was for and how I fixed it.
Only if the solution was particularly clever or hard to understand.
I usually add my name, my e-mail address and the date along with a short description of what I changed, That's because as a consultant I often fix other people's code.
// Glenn F. Henriksen (<email#company.no) - 2008-09-23
// <Short description>
That way the code owners, or the people coming in after me, can figure out what happened and they can get in touch with me if they have to.
(yes, unfortunately, more often than not they have no source control... for internal stuff I use TFS tracking)
While this may seem like a good idea at the time, it quickly gets out of hand. Such information can be better captured using a good combination of source control system and bug tracker. Of course, if there's something tricky going on, a comment describing the situation would be helpful in any case, but not the date, name, or bug number.
The code base I'm currently working on at work is something like 20 years old and they seem to have added lots of comments like this years ago. Fortunately, they stopped doing it a few years after they converted everything to CVS in the late 90s. However, such comments are still littered throughout the code and the policy now is "remove them if you're working directly on that code, but otherwise leave them". They're often really hard to follow especially if the same code is added and removed several times (yes, it happens). They also don't contain the date, but contain the bug number which you'd have to go look up in an archaic system to find the date, so nobody does.
Comments like this are why Subversion lets you type a log entry on every commit. That's where you should put this stuff, not in the code.
I do it if the bug fix involves something that's not straightforward, but more often than not if the bugfix requires a long explanation I take it as a sign that the fix wasn't designed well. Occasionally I have to work around a public interface that can't change so this tends to be the source of these kinds of comments, for example:
// <date> [my name] - Bug xxxxx happens when the foo parameter is null, but
// some customers want the behavior. Jump through some hoops to find a default value.
In other cases the source control commit message is what I use to annotate the change.
Whilst I do tend to see some comments on bugs inside the code at work, my personal preference is linking a code commit to one bug. When I say one I really mean one bug. Afterwards you can always look at the changes made and know which bug these were applied to.
That style of commenting is extremely valuable in a multi-developer environment where there is a range of skills and / or business knowledge across the developers (e.g. - everywhere).
To the experienced knowledgable developer the reason for a change may be obvious, but for newer developers that comment will make them think twice and do more investigation before messing with it. It also helps them learn more about how the system works.
Oh, and a note from experience about the "I just put that in the source control system" comments:
If it isn't in the source, it didn't happen.
I can't count the number of times the source history for projects has been lost due to inexperience with the source control software, improper branching models etc. There is
only one place the change history cannot be lost - and that's in the source file.
I usually put it there first, then cut 'n paste the same comment when I check it in.
No I don't, and I hate having graffiti like that litter the code. Bug numbers can be tracked in the commit message to the version control system, and by scripts to push relevant commit messages into the bug tracking system. I do not believe they belong in the source code, where future edits will just confuse things.
Often a comment like that is more confusing, as you don't really have context as to what the original code looked like, or the original bad behavior.
In general, if your bug fix now makes the code run CORRECTLY, just simply leave it without comments. There is no need to comment correct code.
Sometimes the bug fix makes things look odd, or the bug fix is testing for something that is out of the ordinary. Then it might be appropriate to have a comment - usually the comment should refer back to the "bug number" from your bug database. For example, you might have a comment that says "Bug 123 - Account for odd behavior when the user is in 640 by 480 screen resolution".
If you add comments like that after a few years of maintaining the code you will have so many bug fix comments you wouldn't be able to read the code.
But if you change something that look right (but have a subtle bug) into something that is more complicated it's nice to add a short comment explaining what you did, so that the next programmer to maintain this code doesn't change it back because he (or she) thinks you over-complicated things for no good reason.
No. I use subversion and always enter a description of my motivation for committing a change. I typically don't restate the solution in English, instead I summarize the changes made.
I have worked on a number of projects where they put comments in the code when bug fixes were made. Interestingly, and probably not coincidentally, these were projects which either didn't use any sort of source control tool or were mandated to follow this sort of convention by fiat from management.
Quite honestly, I don't really see the value in doing this for most situations. If I want to know what changed, I'll look at the subversion log and the diff.
Just my two cents.
If the code is corrected, the comment is useless and never interesting to anybody - just noise.
If the bug isn't solved, the comment is wrong. Then it makes sense. :) So just leave such comments if you didn't really solved the bug.
To locate ones specific comment we use DKBUGBUG - which means David Kelley's fix and reviewer can easily identity, Ofcourse we will add Date and other VSTS bug tracking number etc along with this.
Don't duplicate meta data that your VCS is going to keep for you. Dates and names should be in the automatically added by the VCS. Ticket numbers, manager/user names that requested the change, etc should be in VCS comments, not the code.
Rather than this:
//$DATE $NAME $TICKET
//useful comment to the next poor soul
I would do this:
//useful comment to the next poor soul
If the code is on a live platform, away from direct access to the source control repository, then I will add comments to highlight the changes made as a part of the fix for a bug on the live system.
Otherwise, no the message that you enter at checkin should contain all the info you need.
cheers,
Rob
When I make bugfixes/enhancements in third party libraries/component I often make some comments. This makes it easier find and move the changes if I need to use a newer version of the library/component.
In my own code I seldom comments bugfixes.
I don't work on multi-person projects, but I sometimes add comments about a certain bug to a unit test.
Remember, there's no such thing as bugs, just insufficient testing.
Since I do as much TDD as possible (everything else is social suicide, because every other method will force you to work endless hours), I seldomly fix bugs.
Most of the time I add special remarks like this one to the code:
// I KNOW this may look strange to you, but I have to use
// this special implementation here - if you don't understand that,
// maybe you are the wrong person for the job.
Sounds harsh, but most people who call themselves "developers" deserve no other remarks.