Top warning signs of bad code?

[Lee]

Re: Top warning signs of bad code?

Henrik said:[color=blue]
>
>Lee skrev:
>[color=green]
>>
>> So, to you, "lousy software" and "good software" mean the same thing,
>> because both are very loose descriptions of an unspecified degree of
>> quality?[/color]
>
>No, of course not. But one man's "well-tested" program may be
>somerthing another calls "seems to work". Just as one man's "lousy
>program" may be called "good software" by another. As long as we don't
>define our phrases we can use them as we please.[/color]

But you just claimed that "well-tested" meant the same thing as
"seems to work". Are you saying that you now recognizes that,
although not exactly quantified, they are significantly different,
just like "lousy" and "good"?

[Ian Sedwell]

Re: Top warning signs of bad code?

On 2004/09/22 22:38, in article cisrc0011pp@drn .newsguy.com, "Lee"
<REM0VElbspamtr ap@cox.net> wrote:
[color=blue]
> Henrik said:[color=green]
>>
>> Randy Webb skrev:
>>[color=darkred]
>>> Henrik wrote:
>>>
>>>> Lee wrote:
>>>>
>>>>> I said "well-tested", not "seems to work". Fixing code that isn't
>>>>> broken, simply to pass an automated test, is reckless.
>>>>>
>>>>
>>>>
>>>> Excuse me, but what is the difference? A script (or program) that
>>>> is "well-tested" has presumably executed sucessfully in a (large)
>>>> set of more or less artificial states. The larger the set, the
>>>> better is the test.
>>>
>>> The difference is huge. A newbe writes code, tests it in IE, it
>>> "seems to work". An experienced programmer writes code, tests it in
>>> as many browsers/OS as possible. Its "well-tested".
>>>
>>>> "seems to work" seems to cover this nicely.
>>>
>>> No, "well-tested" may be a subset of "seems to work" but it's not a
>>> blanket coverage.[/color]
>>
>> You use many words to agree my point. Whether "well-tested" is a
>> subset (or a superset) of "seems to work" is not relevant; both are
>> very loose descriptions of an unspecified amount of experiments.[/color]
>
> So, to you, "lousy software" and "good software" mean the same thing,
> because both are very loose descriptions of an unspecified degree of
> quality?
>[/color]

So there's a lot to be said for functional program languages, after all.
Lets hear it for good old LISP!

[Ian Sedwell]

Re: Top warning signs of bad code?

On 2004/09/22 22:48, in article M8GdnSATFKytbsz cRVn-iQ@comcast.com, "Randy
Webb" <HikksNotAtHome @aol.com> wrote:
[color=blue]
> Henrik wrote:
>[color=green]
>> Randy Webb skrev:[/color]
>
> <--snip-->
>[color=green][color=darkred]
>>>> "seems to work" seems to cover this nicely.
>>>
>>> No, "well-tested" may be a subset of "seems to work" but it's not a
>>> blanket coverage.[/color]
>>
>>
>> You use many words to agree my point. Whether "well-tested" is a
>> subset (or a superset) of "seems to work" is not relevant; both are
>> very loose descriptions of an unspecified amount of experiments.[/color]
>
> No, I didn't agree with your point. I was pointing out the wording. In
> now way, shape, form or fashion do I agree that "seems to work" code is
> "well-tested" code because they are not even close to being the same thing.
>[/color]

Randy is correct. They are far from being the same thing.

[Randy Webb]

Re: Top warning signs of bad code?

Henrik wrote:[color=blue]
> Randy Webb skrev:
>
>[color=green]
>>Henrik wrote:
>>
>>[color=darkred]
>>>Randy Webb skrev:[/color]
>>
>><--snip-->
>>[color=darkred]
>>>>>"seems to work" seems to cover this nicely.
>>>>
>>>>No, "well-tested" may be a subset of "seems to work" but it's not
>>>>a blanket coverage.
>>>
>>>
>>>You use many words to agree my point. Whether "well-tested" is a
>>>subset (or a superset) of "seems to work" is not relevant; both are
>>>very loose descriptions of an unspecified amount of experiments.[/color]
>>
>>No, I didn't agree with your point. I was pointing out the wording.
>>In now way, shape, form or fashion do I agree that "seems to work"
>>code is "well-tested" code because they are not even close to being
>>the same thing.[/color]
>
>
> Then I wonder what you mean by '"well-tested" may be a subset of "seems
> to work"'. I have probably misunderstood that period.[/color]

Using Numbers as a comparison. 1 is a Number. -1 is a Number. 1 is a
Positive Integer, -1 is not a Positive Integer. Positive Integers are a
sub-set of Numbers, but because something is a Number doesn't make it a
Positive Integer.

Direct comparison in Javascript:

Script 1:

document.all.im ageName.src="so meOtherImage.jp g";

Tested in IE, it "seems to work".

Script 2:

document.images['imageName'].src="someOther Image.jpg";

Tested in IE, it "seems to work".

The second script is "well-tested" though, because its known to work in
almost every browser that supports images. I don't know of a browser
that supports document.images that the second doesn't work in. I only
know of 4 browsers (out of 150 or so that I know of) where the first one
will work.

Both "seem to work", but on the second one is "well-tested".

Makes the well-tested a subset of "seems to work".




--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq

[Robert]

Re: Top warning signs of bad code?

In article <9nfuwixjyzs4.m 914usei26k7.dlg @40tude.net>,
Andrew Thompson <SeeMySites@www .invalid> wrote:
[color=blue][color=green]
> > " Don't use parentheses for subscripting. Not only is it wrong, but only
> > IE will accept it."
> >[/color][/color]
[color=blue]
>[color=green]
> > I know it could be IE only section & validate. But what is the change
> > of change variable reference styles in on script anyway.[/color]
>
> ..could you clarify that last sentence for me?
>
> [ I'm pretty sure it contained something I don't want
> to miss, but I cannot make head nor tail of it! ;-) ][/color]

I isn't all that profound & I wrote it rather late.

I was saying there is the minor chance that the Javascript code could
work on the Internet because it could be in an IE only section of the
code. That is when the same Javascript code runs on Netscape it would
work because in the Netsape case the author would avoid this code.

Then I tried to comment that it would probably be in a section of code
where the author did an explicit check for IE and doing checks for IE
isn't recommended anyway.

Then I thought that what author would change styles of coding to use IE
style selection in the IE only code and W3C style in other sections of
code? So just spotting code like this marks the script not ready for
the Internet.

I think this style of coding is confusing anyway and should not be used:
document.forms[0].total(i).value


Thanks for you interest in avoiding statements like this.

Robert

[Charlie T]

Re: Top warning signs of bad code?

Andrew Thompson <SeeMySites@www .invalid> wrote in message news:<16q4t2hud xv2h$.3ycjalz02 e04.dlg@40tude. net>...[color=blue]
> On Mon, 20 Sep 2004 12:57:28 GMT, Andrew Urquhart wrote:
>[color=green]
> > http://www.developer-x.com/content/innerhtml/[/color]
>
> Thanks Andrew, I've bookmarked that and will have a
> close look over it when I get the chance.[/color]

Very helpful link.

[Dr John Stockton]

Re: Top warning signs of bad code?

JRS: In article <rccharles-BE617A.22415322 092004@news2.we st.earthlink.n
et>, dated Thu, 23 Sep 2004 02:35:49, seen in news:comp.lang. javascript,
Robert <rccharles@my-deja.com> posted :[color=blue]
>
>2) Copyright date if present. If the date is a few years old the code
>will be less likely to work.[/color]

If the date is seemingly current, check that it has not been obtained
from new Date().

--
© John Stockton, Surrey, UK. ???@merlyn.demo n.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/> - FAQish topics, acronyms, & links.

In MS OE, choose Tools, Options, Send; select Plain Text for News and E-mail.

[Dr John Stockton]

Re: Top warning signs of bad code?

JRS: In article <ciscrl$80t$1$8 302bc10@news.de mon.co.uk>, dated Wed, 22
Sep 2004 18:30:27, seen in news:comp.lang. javascript, Richard Cornford
<Richard@litote s.demon.co.uk> posted :[color=blue]
>Dr John Stockton wrote:[/color]
[color=blue][color=green]
>> Suggest eval(...) usually, but not always, bad[/color]
>
>Thinking about the subject some more I am coming to the conclusion that
>where eval is concerned it might be best to describe examples of its
>worst abuses and state them as absolutely indicative of bad code. The
>effect would still be to exclude the massive majority of the public code
>in which eval appears incorrectly.
>
>So, eval used to resolve a constructed dot notation property accessors
>would be a specific example. Along with eval used for sting to number
>type conversion, evaling string literals, and evaling values that are
>not of string type (such as property accessors that can be expected to
>be object references (or null) and numbers). Eliminating code that
>features any of that set of specific eval abuses should have a
>significant impact on the average quality of any remaining examples.[/color]

Agreed. Include those who believe that an assignment of an expression
to a variable must be done as in X = eval(Y+Z) though their code
will probably fail enough other tests too ...

[color=blue][color=green][color=darkred]
>>>Failing to degrade to a viable
>>>web page (for any reason including
>>>the absence of script support) - easily objectively tested
>>> and certainly bad.[/color]
>>
>> Counter-example - my page holidays.htm. Originally, I wrote
>> it in pure HTML; but that expanded and needed annual tiresome
>> updating, which I decline to do. Other than its viable links,
>> the page is of negligible value without javascript.
>> Of course, "viable" is subjective; the scriptless page is
>> a valid page.[/color]
>
>Given that the FAQ states that the default assumption for the group is
>that questions asked relate to scripting of web browsers in a public
>Internet context it doesn't seem unreasonable for quick answers to also
>be written primarily for that context. And while there might be a small
>minority of cases where javascript dependency cannot be realistically
>avoided in the context of the majority of scripts it certainly can, if
>the script is designed for clean degradation from the outset. Making it
>clear that clean degradation should be the expectation from a well
>designed script doesn't seem unreasonable, at minimum it should make
>people aware that the issue exists and encourage them to look at the
>consequences .[/color]

One need only add "unless scripting is fundamental"; consider, for
example, <URL:http://www.merlyn.demo n.co.uk/astro.htm#Calc> as if it
were a complete page. Without script, it serves only to show what it
cannot do.



On == true - ISTM that, while it is perfectly legal and reliable,
and wastes only a few characters (unlike, say, parenthesis-indexing is
eval-indexing) it is a /bad sign/ : a coder who feels it necessary is a
coder whose other code should be treated with suspicion.



It is well-known that certain page-editing tools generate bad and/or
bloated HTML. If there are javascript-generating tools, stand-alone or
included in page-editing ones, which give similarly bad code, then it
would be worth warning against copying their output /verbatim/. How one
tells, I do not know.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/> - FAQqish topics, acronyms & links;
some Astro stuff via astro.htm, gravity0.htm; quotes.htm; pascal.htm; &c, &c.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[Michael Winter]

Re: Top warning signs of bad code?

On Thu, 23 Sep 2004 13:53:43 +0100, Dr John Stockton
<spam@merlyn.de mon.co.uk> wrote:

[snip]
[color=blue]
> One need only add "unless scripting is fundamental"; consider, for
> example, <URL:http://www.merlyn.demo n.co.uk/astro.htm#Calc> as if it
> were a complete page. Without script, it serves only to show what it
> cannot do.[/color]

It must be said that the majority of things I can remember seeing your
pages *do* [1] does not require scripting. You could perform the various
calculations server-side and resend the page with the results. It doesn't
require Javascript, though client-side scripting would be quicker with
less network traffic.

That said, your Javascript pages serve to demonstrate scripts. It would be
senseless to expect them to operate without scripting enabled.

[snip]

Mike


[1] Notable exceptions are tests like the approximate resolution of
setTimeout and the behaviour of the Date object when affected by Daylight
Savings. I'm sure there are others.

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Richard Cornford]

Re: Top warning signs of bad code?

Michael Winter wrote:[color=blue]
> Robert wrote:[/color]
<snip>[color=blue]
> ... . The fact that it's wrong is
> the main point. Perhaps something more direct, like:
>
> "It's incorrect (though IE will accept it)."[/color]
<snip>

Strictly, numerous browsers will support it. If you - typeof - test the
various collections in Opera, Konqueror/Safari or IceBrowser you will
find that the result is 'function'. They can be called and the
parenthesised notation that represents a function call will work with
them.

The reason for preferring the bracket notation is that it works reliably
on every browser that will allow parenthesised access, plus all the
browsers that do not. And on any occasion where one formulation fits all
(collection feature supporting) browsers, cross-browser scripting is
simplified by using that formulation exclusively.

Richard.

[Richard Cornford]

Re: Top warning signs of bad code?

Matt Kruse wrote:[color=blue]
> Richard Cornford wrote:[color=green]
>> Matt Kruse wrote:[color=darkred]
>>> I think clarity of code is absolutely essential if
>>> the code is to be distributed, reused, learned from,
>>> or modified.[/color][/color][/color]
[color=blue][color=green]
>> Four very disparate requirements that are unlikely to
>> simultaneously apply to any one piece of code.[/color]
>
> I disagree, of course. I think most code posted on web
> sites for others to use have those 4 things in mind.[/color]

The majority of code posted to web sites with the apparent intention
that others would use it is so appallingly bad that it is difficult to
see how it could have been created with any design concept let alone
attempting to satisfy 4 simultaneously.

However, I write code with the intention that it be learnt from, and to
facilitate that I formally structure it, heavily comment it and then
comment upon it (see the FAQ notes). I also write code to be re-used,
for which formal structure, adequate comments and suitable documentation
best satisfy that requirement. And I prepare code for distribution, at
which point it loses much of its structure, most of its comments and
probably its meaningful internal identifiers. Even if the javascript is
equivalent (originally identical) in all three cases the observable form
of the results is (and should be) distinct. Trying to wrap all three
requirements up in the same piece of source code is most likely to
produce results ill suited to any of them.
[color=blue][color=green][color=darkred]
>>> They might condense the code, and save a whopping
>>> 1k of data transfer,[/color][/color][/color]
[color=blue][color=green]
>> You just love citing those baseless numbers don't you?[/color]
>
> Yes. Yes I do. They're called approximations based on
> experience with tweaking scripts.[/color]

My code addresses issues that you dismiss as insignificant and so have
never implemented, and you don't understand the techniques I use so you
are in no position to judge the consequences of there application
(beyond dismissing them because your lack of understanding produces a
perception of complexity). This makes me think you have no experience
that you can apply as a basis for approximation.
[color=blue][color=green][color=darkred]
>>> but they make the code much less useable.[/color][/color][/color]
[color=blue][color=green]
>> And you have very vague concept of 'use'.[/color]
>
> In the context of this thread,[/color]

That being the thread with the subject "Top warning signs of bad code?".
[color=blue]
> I think the concept of 'usable' is pretty clear.[/color]

I don't see why it should be as you are the only person to have raised
the subject in this context and when you talk of 'users' it is usually
unclear who you intend the subject to be.
[color=blue]
> We're talking about evaluating code and deciding
> whether it is a good choice to be used, modified, etc.[/color]

No we are not. The subject of this thread is identifying, and excluding,
bad code through the application of formal rules (of some sort or
another). What happens to the code that is not excluded by the (any)
resulting rules has not been laid down. Nor is it a reasonable
expectation that any set of formal rules would be able to eliminate all
bad code, so the residue certainly could not be categorised as 'good
code', or actually be considered suited to any purpose.
[color=blue]
> So in this context,[/color]

Yes?
[color=blue]
> usable probably means usable to the person who is
> going to be using, modifying, etc the code.[/color]

"usable to the person who is going to be using ...", but using for
what? As an example to be learnt from, as a cut-and-paste drop in, as a
starting point for some unspecified elaboration? If it is just a
question of deploying a script on a web site the script best suited to
that use would be a black-box with a simple interface (and probably
pre-minimised source) that did the required job for the least effort on
the part of the individual deploying it.

Anyone wishing to use a third party's script as the starting point for
some other script is going to need to fully understand that script, so
they will appreciate adequate comments, formal structure, and a script
authoring style that is within there comprehension (so dependent on the
knowledge of the individual).

And those interested in learning will have different uses for different
scripts depending on where they are starting form. The novice will have
no use for a script that demonstrates advanced techniques, and an
intermediate to advanced student won't learn much from a script that was
useful to a novice.
[color=blue][color=green]
>> Well you will find that to the typical author of
>> javascript for web pages your style is
>> as incomprehensibl e to them as mine is to you.[/color]
>
> Well, I disagree.[/color]

Then maybe you should spend more time looking at the javascript behind
web sites because it is very clear that the majority of it came into
existence without any involvement on the part of a programmer. Their
creators mostly wouldn't comprehend your object implementations .
[color=blue]
> I try to write code in such a way that anyone familiar
> with similar languages will be able to recognize the same
> constructs, patterns, and style that they are used to
> seeing in their other work.[/color]

Similar languages? You write code so that it can be understood by the
authors of Scheme and Self? Why?

But in reality you mean that you write scripts so that they are familiar
to the authors of the very dissimilar language Java. It isn't actually a
good idea to write javascript that apes Java because you will be
crippling your scripts and achieve no more to than give the programmers
of Java reinforcement for their prejudice that javascript is inferior,
as you demonstrate it not really delivering what Java is good at. There
is more to Java than the pattern of the objects used, there is the whole
object oriented ethos. When javascript apes Java it cannot deliver more
than a shadow of OO, and the Java programmers can recognise that. But
javascript can implement anything so OO design methodologies can be
fully applied javascript authoring, though it is javascript that needs
to be understood in order to achieve that, not Java.

<snip>[color=blue]
> The discussion is about evaluating code which is made
> available for others to use. The topic of this sub-thread
> is how clear and easily-understandable code is better for
> such purposes than complicated, "kewl" code that
> accomplishes the same task.[/color]

Do you really believe that I perceive my code as complex; that I am
masochistic enough to choose the complex over the simple? Do you think
that I have spent my time studying javascript, experimenting with its
application and debating the results on this group out of a desire to
achieve the "kewl"? The reality is that in cross-browser scripting there
are a mass of issues that should be handled, and I am looking for better
ways of handling them. If, as a result of my efforts, I modify the style
I use in implementing scripts then that is the result of informed
judgement and is motivated by a recognition that doing so delivers
tangible benefits.

Those benefits may come form performance improvements, better
encapsulation, fuller application of OO principles, increased code
re-use, improved reliability, etc, but above all the most tangible
benefit is apparent in the time it takes to create new scripts. for
example, that table scrolling script took 6 hours to design, implement,
test and upload (yes I did time the whole process). That is hardly a
symptom of real complexity in the implementation.

You think you can implement equivalent functionality in your preferred
style, so could I, but I choose not to because I know what result would
be, and how it would perform.
[color=blue]
> My point was, some people put up example code that may
> be technically excellent, but probably isn't as good of
> a choice for a person who want to use, learn from, and
> modify an existing solution. Your code was my example.[/color]

If people want to learn how to exploit closures they are not going to do
so from your code. They would be better off reading the examples that I
created for that specific purpose, along with its accompanying
explanation. If they have less ambitious interests then there is plenty
of other code in the FAQ to learn form.
[color=blue][color=green]
>> Why should they, just so you feel better about never
>> bothering to learn how to do anything any better?[/color]
>
> "better" is subjective.[/color]

Better is a relative term and many criteria can be applied to make
objective judgements of it.

<snip>[color=blue]
> And in the context of this discussion, the goal is to
> find the best code to use, learn from, and modify.[/color]

Again, no. The subject of this thread is the identification and
rejection of *bad* code, without any regard for the purpose of that
code.
[color=blue][color=green]
>> Personally I am confused as to why your code features
>> functions that are clearly analogous to 'static' in
>> class-based languages assigned as methods of object instances.[/color]
>
> If you provide an example, I'll tell you why
> I did what I did.[/color]

The first example that comes to hand is be your - DynamicOptionLi st -
object, the constructor of which assigns the globally declared
functions - DOL_populateChi ld -, - DOL_findMatchin gOptionInArray - and -
DOL_addNewOptio nToList - to the - populateChild -, -
findMatchingOpt ionInArray - and - addNewOptionToL ist - properties of the
objects it is constructing. Making them all instance methods, although
none of the functions makes reference to the object instance to which it
is attached, instead acting only on their arguments, even though they
are called as method of the instance.

As the action of those functions relates to the 'class' rather than the
object instance they should be static (and they would have been in
Java), and probably private or protected static at that.
[color=blue]
> *shrugs*[/color]

You may not care, but it is you who are claming that your code
implements constructs and patterns that can be recognised by Java
programmers. An OO programmer will recognise the distinction between a
static method and an instance method.

Richard.

[Andrew Thompson]

Re: Top warning signs of bad code?

On Thu, 23 Sep 2004 13:53:43 +0100, Dr John Stockton wrote:
[color=blue]
> ..If there are javascript-generating tools, stand-alone or
> included in page-editing ones, which give similarly bad code, then it
> would be worth warning against copying their output /verbatim/.[/color]

I have never used tools to generate script.
What are the main contenders? And what sorts of specific
things do they do that might warn against their code?

I would consider browser-sniffing a definite warning,
while merely producing bloated script (possibly due
to bloated mark-up) would be much less so..
[color=blue]
> How one tells, I do not know.[/color]

...nor I, are there any tell-tale signs of the tools in question?

AFAIR one tool seems to prefix everything with MM_ or
similar*, though I cannot immediately recall which.

* I'm here to learn, and code like that hurts my head, so given
there are so many examples of qn.s discussed in this group that
do *not* involve such code, I examine those examples instead. ;-)

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.lensescapes.com/ Images that escape the mundane

[Andrew Thompson]

Re: Top warning signs of bad code?

On Thu, 23 Sep 2004 17:13:26 GMT, Robert wrote:
[color=blue][color=green]
>> [ I'm pretty sure it contained something I don't want
>> to miss, but I cannot make head nor tail of it! ;-) ][/color][/color]
[color=blue]
> I isn't all that profound & I wrote it rather late.[/color]

LOL ..know the feeling!

(big snip)[color=blue]
> Thanks for you interest in avoiding statements like this.[/color]

Thank you for clarifying ( and yes, it was something I wanted to know :-).

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.lensescapes.com/ Images that escape the mundane

[Michael Winter]

Re: Top warning signs of bad code?

On Fri, 24 Sep 2004 01:39:38 +0100, Richard Cornford
<Richard@litote s.demon.co.uk> wrote:
[color=blue]
> Michael Winter wrote:[color=green]
>> Robert wrote:[/color]
> <snip>[color=green]
>> ... . The fact that it's wrong is
>> the main point. Perhaps something more direct, like:
>>
>> "It's incorrect (though IE will accept it)."[/color]
> <snip>
>
> Strictly, numerous browsers will support it. If you - typeof - test
> the various collections in Opera, Konqueror/Safari or IceBrowser you
> will find that the result is 'function'. They can be called and the
> parenthesised notation that represents a function call will work with
> them.[/color]

Hmm, so it does.

I must say I'm confused (so excuse the befuddled thought process that
follows). Why exactly is this syntax supported?

As far as I can see, it's only used for collections. Even IE insists that
arrays are subscripted with square brackets. Collections in the DOM can be
subscripted, but it explicitly states the use of square brackets.

Is it then just a coping measure for IE's collections? Even so, that then
raises the question for why Microsoft[1] decided to allow parentheses for
something that is so much like an array.

[snip]

Mike


[1] I assume it was Microsoft's idea, as Mozilla doesn't allow
parentheses. If it was Netscape's, I'd assume that Mozilla would follow
suit. Unless they decided to "purify" the syntax.

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Henrik]

Re: Top warning signs of bad code?

Lee skrev:
[color=blue]
> But you just claimed that "well-tested" meant the same thing as
> "seems to work". Are you saying that you now recognizes that,
> although not exactly quantified, they are significantly different,
> just like "lousy" and "good"?[/color]

No, no. But I (hoped to) claim that they both are vague expressions
that are used to mean whatever the writer need to express. We need a
way to quantify such expressions.

--
Henrik