Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 2 sur 309 PremièrePremière 123456789101252102 ... DernièreDernière
Affichage des résultats 31 à 60 sur 9247
  1. #31
    En tout cas le popular-front-end est en 1938
    Rust fanboy

  2. #32
    J'ai ajouté trois liens dans le premier message :

    http://tympanus.net/codrops/ - Le "playground" montre plein de techniques intréssantes. Ils ont aussi un post hebdomadaire très sympa pour se tenir au courant.
    http://css-tricks.com/ - La section "Snippets" en particulier rassemble des tas de morceaux de code utiles
    http://codepen.io/ - Plein de démos HTML/CSS/JS et autres expérimentations.

  3. #33
    Merci Skiant pour la création du topic ! Je suis sûr que tu es bien mieux placé pour t'occuper de tout ce bordel

    Mis à part ça, j'ai un problème avec mon exercice de JavaScript : la console d'erreur de FF me met plein de bordel qui n'est pas lié à mon fichier HTML (c'est du script intégré qu'on me demande) et une erreur de syntaxe à la ligne "else if" :

    Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    <html>
    <head>
    	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    	<title>Calculez votre IMC</title>
    </head>
    <body>
    	<script type="text/javascript">
    		// prénom de l'utilisateur
    		var name=prompt("Veuillez saisir votre prénom");
    		// hauteur de l'utilisateur
    		var height=prompt("Veuillez saisir votre hauteur en mètres");
    		// poids de l'utilisateur
    		var weight=prompt("Veuillez saisir votre poids en kilogrammes");
    		// calcul de l'IMC
    		var imc=weight/(height*height);
    		// résultat du calcul
    		alert("L'Indice de Masse Corporel de "+name+" est de "+imc+".");
    		// introduction du titre
    		document.write("<h1>Votre IMC</h1>");
    		//	si l'IMC est inférieur à 20
    		if (imc<20)
    			//fond jaune
    			document.bgColor="yellow";
    			// commentaire sur le résultat
    			document.write("Votre poids est parfois associé à des problèmes de santé chez certaines personnes.");
    		// si l'IMC est supérieur ou égal à 20 et inférieur à 25
    		else if (imc<25)
    			document.bgColor="green";
    			document.write("Votre poids est satisfaisant pour la plupart des personnes.");
    		// si l'IMC est supérieur ou égal à 25 et inférieur à 27
    		else if (imc<27)
    			document.bgColor="yellow";
    			document.write("Votre poids peut entraîner des problèmes de santé chez certaines personnes.");
    		// si l'IMC est supérieur ou égal à 27
    		else
    			document.bgColor="red";
    			document.write("Votre poinds entraîne un risque augmenté de problème de santé.");
    	</script>
    </body>
    </html>
    Le hic, c'est que même le premier prompt ne se lance pas. C'est pas censé bloqué juste à l'endroit où ça couac ?

  4. #34
    il manque les { }
    I'm not gay. My boyfriend is.

  5. #35
    Il te manque les { } autour des if (t'avais pas fait un peu de prog t'avais dit ?)

    C'est comme dans la plupart des langages non-obsolètes modernes : si tu mets pas d'accolades autour des if c'est juste l'instruction suivante qui est exécutée.
    Là il te met des erreurs au niveau des else vu que juste avant le else il y a une instruction qui n'est pas dans un if, le else ne correspond donc à rien.

    Et sinon, oui en général ça bloque juste à l'endroit où ça couac, sauf dans le cas comme ici où tu as une "trop grosse erreur" qui empêche le navigateur de comprendre la structure même du code.

    ---------- Post added at 11h47 ---------- Previous post was at 11h45 ----------

    By the way, "document.bgColor", "document.write" ainsi que le fait de mettre du script dans le <body> c'est pas très conseillé (ce sont des trucs qui se faisaient dans les années 90/2000, c'est à moitié obsolète maintenant), mais j'imagine que c'est dans ton cours.
    Rust fanboy

  6. #36
    C'est comme dans la plupart des langages non-obsolètes modernes : si tu mets pas d'accolades autour des if c'est juste l'instruction suivante qui est exécutée.
    Pas en python.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  7. #37
    Citation Envoyé par rOut Voir le message
    Pas en python.
    Pas en python
    ^
    IndentationError: unindent does not match any outer indentation level
    >>>

    the universal language, this is music

  8. #38
    Citation Envoyé par Tomaka17 Voir le message
    Il te manque les { } autour des if (t'avais pas fait un peu de prog t'avais dit ?)

    C'est comme dans la plupart des langages non-obsolètes modernes : si tu mets pas d'accolades autour des if c'est juste l'instruction suivante qui est exécutée.
    Là il te met des erreurs au niveau des else vu que juste avant le else il y a une instruction qui n'est pas dans un if, le else ne correspond donc à rien.

    Et sinon, oui en général ça bloque juste à l'endroit où ça couac, sauf dans le cas comme ici où tu as une "trop grosse erreur" qui empêche le navigateur de comprendre la structure même du code.

    ---------- Post added at 11h47 ---------- Previous post was at 11h45 ----------

    By the way, "document.bgColor", "document.write" ainsi que le fait de mettre du script dans le <body> c'est pas très conseillé (ce sont des trucs qui se faisaient dans les années 90/2000, c'est à moitié obsolète maintenant), mais j'imagine que c'est dans ton cours.
    Oui, il ne faut peut être pas lui sauter à la gorge tout de suite. C'est le schéma habituelle des cours de prog JS, PHP et consort.
    Tu codes directement dans la page en premier lieu pour apprendre les bases avant d'aborder l'intégration de fichiers externes et les concepts plus abstraits.

  9. #39
    Non non, je n'ai jamais fait de prog pour ma part (quoique j'avais essayé avec JamagicStudio quand j'avais 10 ans, mais c'était peine perdue).

    Ah ben merci, c'est idiot comme erreur et en plus je l'avais devant mes yeux quand je cherchais une solution c'est juste que j'étais tellement obsédé par l'idée que l'erreur était au début que j'ai bêtement manqué de méthodologie.

    Il me faudrait noter quelque part les définitions des commandes. Mon cours est vraiment nul de ce côté.

  10. #40

  11. #41
    Citation Envoyé par IrishCarBomb Voir le message
    Si vous êtes anglophone, je me permets de recommander : http://stackoverflow.com/
    Très juste, j'ajoute.

  12. #42
    Et alsacréations t'aimes pas ?
    Espèce d'alsaçophobe !
    Rust fanboy

  13. #43
    Citation Envoyé par Tomaka17 Voir le message
    [/COLOR]By the way, "document.bgColor", "document.write" ainsi que le fait de mettre du script dans le <body> c'est pas très conseillé (ce sont des trucs qui se faisaient dans les années 90/2000, c'est à moitié obsolète maintenant), mais j'imagine que c'est dans ton cours.
    /chieur
    Pas forcément pour le script dans body.
    Si tu as dix lignes de JavaScript, le foutre en bas du body te fait économiser une requête http.

    MrBeaner : prend les bonnes habitudes, note donc tes variables :

    Code:
    var foo = 1,
        bar = 3,
        foobar = foo - bar;
    Et n'utilise jamais la notation sans accolades pour les conditions. C'est un nid à emmerde :

    Code:
    if (boo === bar) alert("foobar!");      // pas bien
    
    if (boo === bar) 
      alert("foobar!");                     // pas mieux
    
    if (boo === bar) { alert("foobar!"); }      // toujours pas
    
    if (boo === bar) {                            // bien
      alert("foobar!");
    }

  14. #44
    Citation Envoyé par Tomaka17 Voir le message
    Et alsacréations t'aimes pas ?
    Espèce d'alsaçophobe !
    Non, j'ai jamais été fan. J'trouve qu'un tas d'autres sites font la même chose, en mieux, et j'préfère éviter de foutre absolument tous les liens en première page sinon ça n'aura plus aucun intérêt.

    ---------- Post added at 00h50 ---------- Previous post was at 00h38 ----------

    Sinon, y'a des gens qui utilisent RequireJS et Grunt ?
    J'ai un gros projet sur lequel j'commence à avoir pas mal de bordel pour gérer les scripts.

    Le principe, c'est d'avoir plusieurs templates différents (Page X, page Y, page Z) avec chacun le moins de JS possible à charger.

    Pour ça, dans mon grunt.js, j'ai une définition des fichiers JS à générer comme ceci :
    Code:
    view-name: {
        dest: '<%=dirs.dest%>/js/view-name.js',
        src: [
            '<%=dirs.src%>/js/jquery.plugin1.js',
            '<%=dirs.src%>/js/jquery.plugin2.js',
            '<%=dirs.src%>/js/jquery.plugin3.js',
            '<%=dirs.src%>/js/view-default.js',
            '<%=dirs.src%>/js/view-name.js'
        ]
    }
    Et le souci, ça vient quand j'ai des scripts qui ont des dépendances, et autres couilles.
    En prime, comme, bien évidemment, le default contient des trucs utilisés sur toutes les pages, j'me dis que ça serait plus malin de le charger en fichier externe et profiter du cache pour ne plus avoir à le charger après la première page. D'où l'idée de tout gérer avec RequireJS.

    Peut-être même que j'pourrais mettre les plugins en dépendances du script de la vue, histoire de plus avoir à m'emmerder : je fais tourner l'optimisateur de RequireJS sur les fichiers de vues et roule ma poule...

  15. #45
    Citation Envoyé par Mdt Voir le message
    Et n'utilise jamais la notation sans accolades pour les conditions. C'est un nid à emmerde :
    La norme dans ma boite c'est sans accolade pour une seule ligne et toujours retour à la ligne après tout et n'importe quoi pour l'accolade.
    Moi j'ai toujours mis les accolades pour tout et jamais de retour à la ligne pour autre chose que les classes.

    Je les emmerde tiens.

  16. #46
    Citation Envoyé par Mdt Voir le message
    /chieur
    Pas forcément pour le script dans body.
    Si tu as dix lignes de JavaScript, le foutre en bas du body te fait économiser une requête http.

    MrBeaner : prend les bonnes habitudes, note donc tes variables :

    Code:
    var foo = 1,
        bar = 3,
        foobar = foo - bar;
    Et n'utilise jamais la notation sans accolades pour les conditions. C'est un nid à emmerde :

    Code:
    if (boo === bar) alert("foobar!");      // pas bien
    
    if (boo === bar) 
      alert("foobar!");                     // pas mieux
    
    if (boo === bar) { alert("foobar!"); }      // toujours pas
    
    if (boo === bar) {                            // bien
      alert("foobar!");
    }
    Je ne suis pas d'accord, c'est uniquement une question de gout. Le principe c'est avant tout d'être cohérent et de toujours coder de la même manière.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  17. #47
    Citation Envoyé par rOut Voir le message
    Je ne suis pas d'accord, c'est uniquement une question de gout. Le principe c'est avant tout d'être cohérent et de toujours coder de la même manière.
    Et, si tu bosses en équipe, d'avoir les mêmes conventions respectées très précisément par tout le monde, sinon c'est la foire.

  18. #48
    Bien entendu, et comme tu ne peux pas faire plaisir à tout le monde, il faut choisir de manière arbitraire les règles, faute de partir en débat sans fin. Mais les règles peuvent tout à fait décider de tout mettre sur une ligne si le if agit sur une seule ligne.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  19. #49
    D'ailleurs moi je n'aime pas les gens qui se fixent des règles précises sur ces sujets là.
    Pour ma part j'utilise tout ce qui est à ma disposition, à condition que ça rende le code bien présenté et donc lisible. Et je pense que c'est là le truc le plus important.

    Ca m'arrive par exemple de mettre un if sans accolades avec juste une instruction, et puis je remarque que c'est moche et je rajoute des accolades. Ou l'inverse.
    Même chose pour s'il faut mettre le truc derrière le if ou sur la ligne en dessous, ou l'accolades sur une ligne à part, etc.

    EDIT : Et qu'on comprenne à quoi correspond chaque commentaire aussi.
    Rust fanboy

  20. #50
    Citation Envoyé par rOut Voir le message
    Bien entendu, et comme tu ne peux pas faire plaisir à tout le monde, il faut choisir de manière arbitraire les règles, faute de partir en débat sans fin. Mais les règles peuvent tout à fait décider de tout mettre sur une ligne si le if agit sur une seule ligne.
    Effectivement, le consensus ça passe pas souvent. A mon taf, quand on a du faire les règles pour le CSS, ça a été la foire pour savoir comment on organisait les règles à l'intérieur d'un sélecteur. Finalement, le mec qui voulait faire des "blocs logiques séparés par des espaces" a été viré, et moi, qui défendait l'organisation alphabétique, j'ai été promu.

    ---------- Post added at 11h57 ---------- Previous post was at 11h55 ----------

    Citation Envoyé par Tomaka17 Voir le message
    D'ailleurs moi je n'aime pas les gens qui se fixent des règles précises sur ces sujets là.
    Pour ma part j'utilise tout ce qui est à ma disposition, à condition que ça rende le code "bien présenté" et lisible. Et je pense que c'est là le truc le plus important.

    Ca m'arrive par exemple de mettre un if sans accolades avec juste une instruction, et puis je remarque que c'est moche et je rajoute des accolades. Ou l'inverse.
    Même chose pour s'il faut mettre le truc derrière le if ou sur la ligne en dessous, ou l'accolades sur une ligne à part, etc.
    Quand tu bosses tout seul, tu as le luxe de choisir ton style et d'être inconsistant si ça t'amuses.
    Si tu bosses en équipe et que tu nies exprès les conventions d'écriture juste parce que ça t'amuse, tu rends simplement le travail plus difficile pour tout le monde.

  21. #51
    On est bien d'accord qu'une norme est arbitraire et que chacun code comme il aime tant que son équipe le pige, qu'un seul style est maintenu et que ça fonctionne.

    M'enfin là, en l’occurrence, on parle d'un débutant, donc je lui conseille de mettre systématiquement les accolades, tout simplement parce qu'il n'a pas encore l'habitude de gérer le nid à emmerdes en question.

    En JavaScript plus que dans tout autre langage, il faut prendre des habitudes saines. Sinon ça donne des trucs... brrr...

    "blocs logiques séparés par des espaces" a été viré, et moi, qui défendait l'organisation alphabétique, j'ai été promu.
    Perso je préfère(ais, parce que j'ai plus énormément l'occasion de faire du css) des blocs logiques non séparés par des espaces.
    En gros positionement (dont float), display, dimensions, margpaddbord, shadows, transformations, transitions, texte.

  22. #52
    Citation Envoyé par Skiant Voir le message
    Quand tu bosses tout seul, tu as le luxe de choisir ton style et d'être inconsistant si ça t'amuses.
    Si tu bosses en équipe et que tu nies exprès les conventions d'écriture juste parce que ça t'amuse, tu rends simplement le travail plus difficile pour tout le monde.
    Bah justement non, ces petits détails ça rend pas le travail plus difficile pour tout le monde.
    Pour les trucs importants comme les noms de fonctions, de classes et de variables globales, ou bien pour ce dont tu parles avec les blocs logiques/alphabétique, c'est normal qu'on fixe une norme et que tout le monde la reste.

    Mais les accolades après le "if", ou pour rester dans le sujet s'il faut un espace ou non avant et après le ':' dans les règles CSS, pour moi ça rentre dans la catégorie "on en a rien à foutre".
    Même chose pour l'alignement "public:/private:", l'alignement des "cases" dans un switch/case, la ligne exprès pour l'accolade ouvrante, une ligne par sélecteur en cas de virgule, etc.


    En ce qui concerne le "nid à emmerdes", j'ai l'impression que t'as tellement l'habitude de mettre des accolades que tu penses que ça va être chiant si tu n'en mets pas.
    Mais même les débutants ne font quasiment jamais d'erreur à ce niveau-là une fois qu'ils ont compris la règle.
    Tu vas sur stackoverflow ou n'importe quel forum pour débutants, tu ne verras jamais personne avoir un problème comme mrbeaner plus haut, à moins qu'il ne soit pas au courant comme c'était le cas pour lui.
    Rust fanboy

  23. #53
    Citation Envoyé par Tomaka17 Voir le message
    Bah justement non, ces petits détails ça rend pas le travail plus difficile pour tout le monde.
    Pour les trucs importants comme les noms de fonctions, de classes et de variables globales, ou bien pour ce dont tu parles avec les blocs logiques/alphabétique, c'est normal qu'on fixe une norme et que tout le monde la reste.

    Mais les accolades après le "if", ou pour rester dans le sujet s'il faut un espace ou non avant et après le ':' dans les règles CSS, pour moi ça rentre dans la catégorie "on en a rien à foutre".
    Même chose pour l'alignement "public:/private:", l'alignement des "cases" dans un switch/case, la ligne exprès pour l'accolade ouvrante, etc.


    En ce qui concerne le "nid à emmerdes", j'ai l'impression que t'as tellement l'habitude de mettre des accolades que tu penses que ça va être chiant si tu n'en mets pas.
    Mais même les débutants ne font quasiment jamais d'erreur à ce niveau-là une fois qu'ils ont compris la règle.
    Tu vas sur stackoverflow ou n'importe quel forum pour débutants, tu ne verras jamais personne avoir un problème comme mrbeaner plus haut, à moins qu'il ne soit pas au courant comme c'était le cas pour lui.
    Par exemple dans ma boite, j'ai un mec qui refuse de suivre un guide de style précis, il saute systématiquement une ligne toute les lignes et deux quand j'en sauterais une. Et bien rien que ça, ça rend le tout illisible, incompréhensible, incohérent et donc moche, et plus difficilement maintenable par rapport au reste du code. Ca ne rend pas les choses plus difficiles, il suffit soit 1) d'être rigoureux (et si tu manques de rigueur pour le style, ça n'est pas bon signe pour le reste), soit 2) d'utiliser un indenteur automatique avec des paramètres bien précis.

    Pour un débutant, je pense que c'est important d'indiquer et d'expliquer l'erreur, et d'expliquer qu'un style cohérent aide à limiter les erreurs potentielles. Mais imposer un style particulier, je ne pense pas que ce soit une bonne idée. Mettre systématiquement des accolades est sans doute un bon style à utiliser pour un débutant, mais pour les retours à la ligne, c'est une préférence personelle.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  24. #54
    Citation Envoyé par rOut Voir le message
    Par exemple dans ma boite, j'ai un mec qui refuse de suivre un guide de style précis, il saute systématiquement une ligne toute les lignes
    Du code double-space ? C'est pour l'imprimer et noter les fautes dans les interlignes comme pour les dictées ?

  25. #55
    Ouais, c'est chaud. Il met aussi des espaces avant et après les parenthèses...
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  26. #56
    Citation Envoyé par Mdt Voir le message
    Perso je préfère(ais, parce que j'ai plus énormément l'occasion de faire du css) des blocs logiques non séparés par des espaces.
    En gros positionement (dont float), display, dimensions, margpaddbord, shadows, transformations, transitions, texte.
    Ouais, sauf que l'ordre des blocs logiques, c'est une règle arbitraire de plus qu'il faut apprendre à mémoriser. Tout le monde ne penserait pas à organiser ses blocs de la même façon et si tu veux avoir un truc qui tienne dans toute l'équipe, tout le monde doit apprendre à les organiser de la même manière.

    L'ordre alphabétique en anglais, c'est clair, net, précis et tout le monde a le même. Donc pour du boulot solo, ouais, les blocs logiques c'est pas con.
    Pour du boulot en équipe, la meilleure des règles c'est celle qui ne nécessite aucun effort pour être mémorisée.

  27. #57
    Les normes de dév, c'est un sujet chaud comme la braise. Pour en avoir mis en place (le chef, c'était moi), j'en retiens qu'on ne peut pas tout imposer.

    Donc, comme Tomaka, il y a les trucs importants (règles de nommage classes méthodes etc...) et il faut lâcher du lest sur les trucs mineurs comme les espaces et les accolades. Je ne connais pas à un développeur qui n'aie pas ses propres convictions absolue (voir exemples plus haut) ou qui soit capable de se plier intégralement à des règles existantes.

    Donc comme avec les mômes, tu laisse un peu de liberté pour être sur que les trucs importants soient respectés. Et effectivement, le coup des accolades, je pense qu'un débutant se fera avoir qu'une fois.

    Ah et sinon, perso, je préfère du code compact, donc j'aime pas trop les accolades et les lignes vides. Mais c'est perso.

  28. #58
    Surtout que dans certains cas c'est plus lisible de mettre en ligne donc imposer de mettre les accolades à la ligne ou pas c'est un peu con.
    Du style personnelement je trouve ceci plus lisible :
    Code:
    if(test == "bla")    fctUno();
    if(test == "blabla") fctDos();
    if(test == "error")  return false;
    que cela :
    Code:
    if(test == "bla")
    {
        fctUno();
    }
    
    if(test == "blabla")
    {
        fctDos();
    }
    
    if(test == "error")
    {
        return false;
    }
    Pour les taquins je précise que c'est pas du vrai code. C'est qu'un exemple.

  29. #59
    Citation Envoyé par Mdt Voir le message
    MrBeaner : prend les bonnes habitudes, note donc tes variables :

    Code:
    var foo = 1,
        bar = 3,
        foobar = foo - bar;
    J'ai pas compris là. Pourquoi je devrais faire ça ? Tu veux attribuer la valeur numérique "-2" à la variable foobar ?

    Merci d'être patient je n'ai qu'un cours à mon actif et pas des meilleurs

    ---------- Post added at 16h43 ---------- Previous post was at 16h30 ----------

    Et puis vous pensez quoi de ce répertoire de propriétés HTML/CSS/JS : http://dochub.io/ ? Il prends un moment à se charger mais je le trouve pratique (à condition de ne chercher que les explications en fonction des propriétés et pas les propriétés en fonction de leur explication).

    ---------- Post added at 16h53 ---------- Previous post was at 16h43 ----------

    Et y a pas sitepoint en premier post ?

  30. #60
    Je voulais juste pointer que répéter les var n'était pas utile, même si tu manipules des variables que tu viens de déclarer.
    Exemple réel (enfin, navigateurs modernes only) :

    Tu peux faire :

    Code:
    var largeur = window.innerWidth;
    var hauteur = window.innerHeight;
    var ratio = largeur / hauteur;
    Mais tu peux aussi faire :

    Code:
    var largeur = window.innerWidth,
        hauteur = window.innerHeight,
        ratio = largeur / hauteur;
    Là encore, question de style, mais ça rend les déclarations plus nettes.

    La prochaine fois, nous verrons comment utiliser la notation ternaire pour déclarer des variables vraiment proprement

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •